coordinates.html0000664000175000017500000015056514744715207014501 0ustar jfpiollejfpiolle 6. Coordinate variables — The Recommended GHRSST Data Specification (GDS)

6. Coordinate variables#

NetCDF coordinate variables provide scales for the space and time axes for the multidimensional data arrays, and must be included for all dimensions that can be identified as spatio-temporal axes.

Coordinate arrays are used to geolocate data arrays on non-orthogonal grids, such as images in the original pixel/scan line space, or complicated map projections. Required attributes are units and _FillValue. Elements of the coordinate array need not be monotonically ordered. The data type can be any and scaling may be implemented if required. add_offset and scale_factor have to be adjusted according to the sensor resolution and the product spatial coverage. If the packed values can not stand on a short, float can be used instead (multiplying the size of these variables by two).

6.1. Temporal coordinates#

time is the reference time of the SST data array. The GDS-2.1r0 specifies that this reference time should be extracted or computed to the nearest second and then coded as continuous UTC time coordinates in seconds from 00:00:00 UTC January 1, 1981 (which is the definition of the GHRSST origin time, chosen to approximate the start of useful AVHRR SST data record). Note that the use of UDUNITS in GHRSST implies that that calendar to be used is the default mixed Gregorian/Julian calendar.

The reference time used is dependent on the of the data and is defined as follows:

Processing level

Reference time

L2P

start time of granule

L3U

start time of granule

L3C

centre time of the collation window

L3S

centre time of the collation window

L4

nominal time of the analysis

The coordinate variable time is intended to minimize the size of the sst_dtime variable (e.g., see Section 7.2.2), which stores offsets from the reference time in seconds for each SST pixel. time also facilitates aggregation of all files of a given dataset along the time axis with such tools as THREDDS or when building data cubes.

6.2. Spatial coordinates#

x (columns) and y (lines) grid dimensions are referred either as lat and lon or as ni and nj. lon and lat must be used if data are mapped on a regular grid (some geostationary products). ni and nj are used if data are mapped on a non-regular grid (curvilinear coordinates) or following the sensor scanning pattern (scan line, swath). It is preferred that ni should be used for the across-track dimension and nj for the along-track dimension.

Coordinate vectors are used for data arrays located on orthogonal (but not necessarily regularly spaced) grids, such as a geographic (lat-lon) map projections. The only required attribute is units. The elements of a coordinate vector array should be in monotonically increasing or decreasing order. The data type can be any and scaling may be implemented if required.

A coordinates variable attribute (coordinates = "lon lat" ;) must be provided if the data are on a non-regular lat/lon grid (map projection or swath data).

A grid_mapping variable attribute (grid_mapping = "<projection name>" ;) must be provided if the data are mapped following a projection. Refer to the CF convention[1] for standard projection names.

Note on lat/lon arrays

lat and lon arrays are the only arrays stored as float in GHRSST product files and therefore can represent a major fraction of the overall data volume. As an optimization factor, producers are encouraged to make use of the least_significant_digit argument when creating these NetCDF variables (refer for instance to https://unidata.github.io/netcdf4-python/): in most current GHRSST products, there is no need for a precision larger than 3 digits and it can be a big volume saver.

6.2.1. Regular latitude/longitude grids#

This is the simplest case. Many Level 3 and Level 4 products as well as some geostationary L2P products are provided on a regular lat/lon grid. On such a projection, only two coordinate variables are requested and they can be stored as vector arrays. Longitudes should range from -180 to +180, corresponding to 180 degrees West to 180 degrees East. Latitudes should range from -90 to +90, corresponding to 90 degrees South to 90 degrees North. There should be no _FillValue for latitude and longitude and all SST pixels should have a valid latitude and longitude value.

It is recommended that for Level 3 and Level 4 data products the time dimension be specified as unlimited. Note that the time dimension for L2P data files is strictly defined as time=1 (unlimited dimension not allowed). This strict definition is because L2P data are swath based and the geospatial information may change across consecutive time slabs. Although in GHRSST L3 and L4 granules there is only one time dimension and variable time has only one value (seconds since 1981), setting an unlimited dimension for time dimension will allow netCDF tools and utilities to easily concatenate (and average for example) a series of time consecutive GHRSST granules. The following CDL is provided as an example:

netcdf example {
    dimensions:
        lat = 1801 ;
        lon = 3600 ;
        time = UNLIMITED ; // (strictly set to 1 for L2P)
    variables:
...
}

For these cases, dimension and coordinate variables shall be used for a regular lat/lon grid as shown in Table 6.1. No specific variable attributes are required for other variables (like sea_surface_temperature as shown in the example given in Table 6.1).

Table 6.1 Example CDL for geographic regular latitude/longitude grids#

geographic regular latitude/longitude grids

netcdf regular_grid {
dimensions:
	time = UNLIMITED ; // (1 currently)
	lat = 1800 ;
	lon = 3600 ;
variables:
	int64 time(time) ;
		time:axis = "T" ;
		time:long_name = "reference time of sst file" ;
		time:standard_name = "time" ;
		time:coverage_content_type = "coordinate" ;
		time:units = "seconds since 1981-01-01" ;
		time:calendar = "proleptic_gregorian" ;
	float lat(lat) ;
		lat:axis = "Y" ;
		lat:long_name = "latitude" ;
		lat:standard_name = "latitude" ;
		lat:coverage_content_type = "coordinate" ;
		lat:units = "degrees_north" ;
		lat:comment = "geographical coordinates, WGS84 projection" ;
		lat:valid_range = -90., 90. ;
	float lon(lon) ;
		lon:axis = "X" ;
		lon:long_name = "longitude" ;
		lon:standard_name = "longitude" ;
		lon:coverage_content_type = "coordinate" ;
		lon:units = "degrees_east" ;
		lon:comment = "geographical coordinates, WGS84 projection" ;
		lon:valid_range = -180., 180. ;
	short sst_dtime(time, lat, lon) ;
		sst_dtime:_FillValue = -32768s ;
		sst_dtime:long_name = "time difference from reference time" ;
		sst_dtime:coverage_content_type = "coordinate" ;
		sst_dtime:units = "s" ;
		sst_dtime:comment = "time plus sst_dtime gives seconds after 00:00:00 UTC January 1, 1981" ;
		sst_dtime:valid_range = -32767s, 32767s ;
		sst_dtime:add_offset = 0. ;
		sst_dtime:scale_factor = 1. ;
	short sea_surface_temperature(time, lat, lon) ;
		sea_surface_temperature:_FillValue = -32768s ;
		sea_surface_temperature:long_name = "Skin temperature of the sea surface" ;
		sea_surface_temperature:standard_name = "sea_surface_skin_temperature" ;
		sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
		sea_surface_temperature:units = "K" ;
		sea_surface_temperature:comment = "These SST values are representative of the top 10 micrometers of the sea surface and were generated on a regular grid" ;
		sea_surface_temperature:valid_range = -200s, 5000s ;
		sea_surface_temperature:add_offset = 273.15 ;
		sea_surface_temperature:scale_factor = 0.01 ;
}

6.2.2. Non-regular latitude/longitude grids (projection)#

For gridded data using a specific projection (such as stereographic projection), lat/lon have to be stored in 2-D arrays. When data are gridded following the sensor pattern, no projection can be associated and lat/lon data have to be stored in 2-D arrays. Dimensions cannot be referred to as lat/lon anymore since the x and y axes of the grid are not related to the latitude or longitude axis. Each variable must explicitly provide a reference to its coordinate variables (coordinates variable attribute) and to the related projection (grid_mapping variable attribute) described in a specific variable (for example, Lambert_Azimuthal_Grid", in the example given in Table 6.2, refer to CF convention [1] for standard projection names).

In these cases, dimension and coordinate variables shall be used for a non-regular lat/lon grid (projection) as shown in Table 6.2. A specific projection coordinate variable shall be added (for example, Lambert_Azimuthal_Grid), following the CF-1.7 or later convention. The specific variable attributes coordinates = "lon lat" andgrid_mapping = "Lambert_Azimuthal_Grid" are required for each other variables (like sea_surface_temperature in the example given in Table 6.2).

Note that variable attributes such as grid_mapping may be set differently (when using a different kind of projection) or completely removed (for swath products or regular grids if required).

Table 6.2 Example CDL for non-regular latitude/longitude grids (projection)#

non-regular latitude/longitude grids (projections)

netcdf nonregular_grid_projection {
dimensions:
	time = UNLIMITED ; // (1 currently)
	nj = 40000 ;
	ni = 1000 ;
variables:
	int64 time(time) ;
		time:axis = "T" ;
		time:long_name = "reference time of sst file" ;
		time:standard_name = "time" ;
		time:coverage_content_type = "coordinate" ;
		time:units = "seconds since 1981-01-01" ;
		time:calendar = "proleptic_gregorian" ;
	short sst_dtime(time, nj, ni) ;
		sst_dtime:_FillValue = -32768s ;
		sst_dtime:long_name = "time difference from reference time" ;
		sst_dtime:coverage_content_type = "coordinate" ;
		sst_dtime:units = "s" ;
		sst_dtime:grid_mapping = "lambert_Azimuthal_Grid" ;
		sst_dtime:comment = "time plus sst_dtime gives seconds after 00:00:00 UTC January 1, 1981" ;
		sst_dtime:add_offset = 0. ;
		sst_dtime:scale_factor = 1. ;
		sst_dtime:coordinates = "Lambert_Azimuthal_Grid lat lon" ;
	short sea_surface_temperature(time, nj, ni) ;
		sea_surface_temperature:_FillValue = -32768s ;
		sea_surface_temperature:long_name = "Skin temperature of the sea surface" ;
		sea_surface_temperature:standard_name = "sea_surface_skin_temperature" ;
		sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
		sea_surface_temperature:units = "K" ;
		sea_surface_temperature:grid_mapping = "Lambert_Azimuthal_Grid" ;
		sea_surface_temperature:add_offset = 273.15 ;
		sea_surface_temperature:scale_factor = 0.01 ;
		sea_surface_temperature:coordinates = "Lambert_Azimuthal_Grid lat lon" ;
	float lat(nj, ni) ;
		lat:long_name = "latitude" ;
		lat:standard_name = "latitude" ;
		lat:coverage_content_type = "coordinate" ;
		lat:units = "degrees_north" ;
		lat:valid_range = -90.f, 90.f ;
	float lon(nj, ni) ;
		lon:long_name = "longitude" ;
		lon:standard_name = "longitude" ;
		lon:coverage_content_type = "coordinate" ;
		lon:units = "degrees_east" ;
		lon:valid_range = -180.f, 180.f ;
	int Lambert_Azimuthal_Grid ;
		Lambert_Azimuthal_Grid:grid_mapping_name = "lambert_azimuthal_equal_area" ;
		Lambert_Azimuthal_Grid:longitude_of_projection_origin = 0. ;
		Lambert_Azimuthal_Grid:latitude_of_projection_origin = 90. ;
		Lambert_Azimuthal_Grid:false_easting = 0. ;
		Lambert_Azimuthal_Grid:false_northing = 0. ;
		Lambert_Azimuthal_Grid:semi_major_axis = 6378137. ;
		Lambert_Azimuthal_Grid:inverse_flattening = 298.257223563 ;
		Lambert_Azimuthal_Grid:proj4_string = "+proj=laea +lon_0=0 +datum=WGS84 +ellps=WGS84 +lat_0=90.0" ;
}

6.2.3. Non-regular latitude/longitude grids (projection) – alternative without explicit latitude/longitude#

For gridded data using a fixed specific projection (such as geostationary projection), the same lat/lon 2-D arrays are repeated from file to file. If a fixed projection can be associated to lat/lon data, it is also permitted by CF convention to provide a projection variable defining this projection, instead of providing explicit latitude/longitude 2-D arrays as in the previous section. This usually allows to save significant storage (which is interesting for products with a high temporal repetitiveness such as geostationary products in satellite projection) while being less user friendly since users will have to calculate their own latitude/longitude 2-D arrays from the projection parameters (this is done automatically in some CF compliant tools). The projection variable must be named with the projection name used in the product (like geostationary below). It is dimensionless and of type int. The naming and content of this projection variable is described in CF conventions[1].

The x (abscissa) and y (ordinate) rectangular coordinates must be provided in ni and nj variables, identified by the standard_nameattribute values projection_x_coordinate and projection_y_coordinate respectively. In the case of this geostationary projection, the projection coordinates in this projection are directly related to the scanning angle of the satellite instrument, and their units are radians.

Each variable must explicitly provide a reference to its coordinate variables (coordinates variable attribute) and to the related projection (grid_mapping variable attribute) described in a specific variable (e.g. geostationary in the example given in Table 6.3; refer to CF convention[1] for standard projection names).

In these cases, dimension and coordinate variables shall be used for a non-regular lat/lon grid (projection) as shown in Table 6.3. A specific projection coordinate variable shall be added (for example, geostationary), following the CF-1.7 or later convention. The specific variable attributes coordinates = "nj ni" and grid_mapping = "geostationary" are required for each other variables (like sea_surface_temperature in the example given in Table 6.3).

Table 6.3 Example CDL for Non-regular latitude/longitude grids (projections) alternative form with no explicit latitudes/longitudes#

non-regular latitude/longitude grids (projections) with no explicit latitude/longitude

netcdf nonregular_grid_projection_no_latlon {
dimensions:
	time = UNLIMITED ; // (1 currently)
	nj = 40000 ;
	ni = 1000 ;
variables:
	int64 time(time) ;
		time:axis = "T" ;
		time:long_name = "reference time of sst file" ;
		time:standard_name = "time" ;
		time:coverage_content_type = "coordinate" ;
		time:units = "seconds since 1981-01-01" ;
		time:calendar = "proleptic_gregorian" ;
	float nj(nj) ;
		nj:long_name = "y coordinate of projection" ;
		nj:standard_name = "projection_y_coordinate" ;
		nj:axis = "Y" ;
		nj:coverage_content_type = "coordinate" ;
		nj:units = "radian" ;
		nj:valid_range = -0.151844f, 0.151844f ;
	float ni(ni) ;
		ni:long_name = "x coordinate of projection" ;
		ni:standard_name = "projection_x_coordinate" ;
		ni:axis = "X" ;
		ni:coverage_content_type = "coordinate" ;
		ni:units = "radian" ;
		ni:valid_range = -0.151844f, 0.151844f ;
	short sst_dtime(time, nj, ni) ;
		sst_dtime:_FillValue = -32768s ;
		sst_dtime:long_name = "time difference from reference time" ;
		sst_dtime:coverage_content_type = "coordinate" ;
		sst_dtime:units = "s" ;
		sst_dtime:grid_mapping = "geostationary" ;
		sst_dtime:comment = "time plus sst_dtime gives seconds after 00:00:00 UTC January 1, 1981" ;
		sst_dtime:add_offset = 0. ;
		sst_dtime:scale_factor = 1. ;
		sst_dtime:coordinates = "geostationary" ;
	short sea_surface_temperature(time, nj, ni) ;
		sea_surface_temperature:_FillValue = -32768s ;
		sea_surface_temperature:long_name = "Skin temperature of the sea surface" ;
		sea_surface_temperature:standard_name = "sea_surface_skin_temperature" ;
		sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
		sea_surface_temperature:units = "K" ;
		sea_surface_temperature:grid_mapping = "geostationary" ;
		sea_surface_temperature:comment = "These SST values are representative of the top 10 micrometers of the sea surface over the native geostationary satellite grid" ;
		sea_surface_temperature:add_offset = 273.15 ;
		sea_surface_temperature:scale_factor = 0.01 ;
		sea_surface_temperature:coordinates = "geostationary" ;
	int geostationary ;
		geostationary:grid_mapping_name = "geostationary" ;
		geostationary:semi_major_axis = 6378137. ;
		geostationary:semi_minor_axis = 6356752.314245 ;
		geostationary:inverse_flattening = 298.257223563 ;
		geostationary:perspective_point_height = 35786023. ;
		geostationary:longitude_of_projection_origin = 0. ;
		geostationary:latitude_of_projection_origin = -75. ;
		geostationary:false_easting = 0. ;
		geostationary:false_northing = 0. ;
		geostationary:sweep_angle_axis = "x" ;
		geostationary:horizontal_datum_name = "WGS_1984" ;
		geostationary:reference_ellipsoid_name = "WGS 84" ;
		geostationary:prime_meridian_name = "Greenwich" ;
		geostationary:geographic_crs_name = "GEOS" ;
}

6.2.4. Non-regular latitude/longitude grids (swath)#

In this case where data are gridded following the sensor pattern, no projection can be associated and lat/lon data have to be stored in 2-D arrays, as it is the case for along-swath data for low earth orbiting sensors or geostationary orbiting sensor data in their native projection. Therefore it only applies to L2P processing level products.

Dimensions cannot be referred to as lat/lon anymore since x and y axes of the grid are no more related to the latitude or longitude axis. Instead, dimensions ni and njshould be used to describe the swath. As a best practice, the ni dimension should refer to the cross-track direction and the nj dimension should refer to the along-track direction of a polar orbiting (or similar) satellite sensor swath. For geostationary sensors ni also refers to the cross-disk direction and nj the along-disk direction. Each variable must explicitly provide a reference to its coordinate variables (using the coordinates variable attribute) and pixel times must be encoded using the combination of timeand sst_dtime coordinate variables.

Dimension and coordinate variables shall be used for a non-regular lat/lon grid (swath product file) as shown in Table 6.4. The specific variable attribute coordinates = "lon lat" is required for each of the variables (like sea_surface_temperature below).

Table 6.4 Example CDL for non-regular latitude/longitude grids (swath)#

non-regular latitude/longitude coordinates

netcdf nonregular_grid {
dimensions:
	time = 1 ;
	nj = 40000 ;
	ni = 1000 ;
variables:
	int64 time(time) ;
		time:axis = "T" ;
		time:long_name = "reference time of sst file" ;
		time:standard_name = "time" ;
		time:coverage_content_type = "coordinate" ;
		time:units = "seconds since 1981-01-01" ;
		time:calendar = "proleptic_gregorian" ;
	short sst_dtime(time, nj, ni) ;
		sst_dtime:_FillValue = -32768s ;
		sst_dtime:long_name = "time difference from reference time" ;
		sst_dtime:coverage_content_type = "coordinate" ;
		sst_dtime:units = "s" ;
		sst_dtime:comment = "time plus sst_dtime gives seconds after 00:00:00 UTC January 1, 1981" ;
		sst_dtime:add_offset = 0. ;
		sst_dtime:scale_factor = 1. ;
		sst_dtime:coordinates = "lat lon" ;
	short sea_surface_temperature(time, nj, ni) ;
		sea_surface_temperature:_FillValue = -32768s ;
		sea_surface_temperature:long_name = "Skin temperature of the sea surface" ;
		sea_surface_temperature:standard_name = "sea_surface_skin_temperature" ;
		sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
		sea_surface_temperature:units = "K" ;
		sea_surface_temperature:add_offset = 273.15 ;
		sea_surface_temperature:scale_factor = 0.01 ;
		sea_surface_temperature:coordinates = "lat lon" ;
	float lat(nj, ni) ;
		lat:long_name = "latitude" ;
		lat:standard_name = "latitude" ;
		lat:coverage_content_type = "coordinate" ;
		lat:units = "degrees_north" ;
	float lon(nj, ni) ;
		lon:long_name = "longitude" ;
		lon:standard_name = "longitude" ;
		lon:coverage_content_type = "coordinate" ;
		lon:units = "degrees_east" ;
}

genindex.html0000664000175000017500000003231314744715212013752 0ustar jfpiollejfpiolle Index — The Recommended GHRSST Data Specification (GDS)

Index

_images/0000775000175000017500000000000014744715212012665 5ustar jfpiollejfpiolle_images/sst-definition.gif0000664000175000017500000006063114625553251016322 0ustar jfpiollejfpiolleGIF89a9++%4+7 4('''%+6+377*%74+777 Hl ,N6k)5N+.o4K:F.Fs/CU-NqOL,J6(p| !f3m/)\;PXFRG-Ql4oU nO.zdvh2OONNSo[mGRfsoQMb_kkoRppp((--'8,00"4-Y5h>xM.G.P4kEN1d7BZMrLxmwTJBWWcLklNxeix^7gi@{vyCޅ DܹS"?/b{.rk<7 X3n T@@4GTcTs%cqtbBD-|etu}m B_Fq !IHI!|ɦ|)i]zވtsAHfhAtV8⤰U&uJЦa۔@ BH 9jж*u p ddsZϷ-B6R;@fAC:hAwd3+MZr+!˵@Ď %§, 4)1Z;gٙ]˟-إ@,xl%A&|̲l\j`&mD7t(7:ݔ2"6+d>>FZwv\cqB+ɹe|P bAŷFu|}{`$".a(49ƀ;I'%{wߜSu`c˾AsT 8٬>nL6a&0'h㳝 h d& PQb N&: f*ut⟠N9J3ǿԝ%" LZp;8Fn:,-P~L :Sj hպ  :@V `J1[ݰs./k]NH/H, 6|R;(7b8saVHFM5a,""ΜQ!߉V:rnnbմ.VPDhBorHrVgUc>CZoxbhrQ쏒sR]r^#7]ҊPIZ̥.w^ 0IbL2̄C0` =cF>laG r];}t]n?! 2GdzV9HR`#}رj52J 2BxGpGJ ꡷Li/;$kErCbfݦ@pߍ 5s弑=Z>7R HX>r֌{ ǀ} Xk]ip @Iilt E;C!A̭q'dHw#J6m鵍 a)6D";J@QHflq:cWgY8'=:N|G5XĞ3$,b$PW }!c\a?܁xO?DZfk~sCWC,0u"HҒ4>W'pdπr#pF#ezQ}8Z' >=^~{b5ʧXh.u2H1P {ZVc.u6H>"qRx'7SKd9,y^4( nv~} 8xoX) Z?5%>]_MdKyGxtI]L)w2gJ1!ZWU~~ayAa:eQrD D?(! ^ӂ `aQo:?( 3[qPBHAMx!>CVh>X'7>Y8L(DAG._Q, *:1fGh{.6хQ LwXm5ч+$(m?+Q.!$ `XC zxXS_Xip$X/%"!#|AVȘʸ،˨!ΘxؘDӍ8D 帎؍%ӎD p ؏9#yhHJ"C:$~:2txqsb%y$&,h -0В+ɓ1.2ٓ0I.9&ٔNPR9NNAA& ^ ဖjlnٖprfrxyzi" !q ?@qѡ S)R1 ,$c脽84 cq s ĆV`$Y1ِ(570i@+- +^bL߲ 9Z?$PBX9. Y!)X ca߀5yyL5i>A(8PV@M 霁p^0S**A]B Em08:q a9o Je&I d1QBx):dPĘZFq*Hvp ",P#P pP^YX=EpJ:vRa2( Ιx꣊z!J : 2%r8s0eT.xn UZsp oЪقP&R&jP0LWx!E}Q;Dcڂ 6êZKp4`BƆOrӔL{J=D:ڂK5Sff`yd[aUIJ*P vp**!b$-'` 0ĄP3f%bp  VWhv D4+Ъι $(\ z+ tVSmg\+Y)Usi"^aCaH5<so $y|/gW%G_Ko& 8+^a.P LJH oI2bvwfwp8~+jU[TRge!AG󋫻`:LOH뼏{aUAZ P4o1y.Weu_Vs#lB©۹KY,^Ss{THmEkEZ@ @V^X*Q1#@\ ;Ÿڻ^aYU0ͻI+o` AK@8@.|),йS! N} ȂL_ |$@vP _<ܻ`` @"̼_S lx+TÆCak 1L#'젼;JKJ` pLƞPKJ[+p0ܑ?Q ȜC 0 \$νŗ[a1IcLs;⣸+e?g :[7)-DA-|\7?hpD )a Щ BD2g ,D\>=P@q*Q ]휨5-0- `]}:=QȞg& a=T P^ $#ל ԧXb P]ׅ* ӖDT*|]՛ q% nmHHLn& jsHa 0n] o* i'`}D $`Pn`|0| :0 ؐ $b7F%SwwD`י+# ^ H$b=wxV0W>0` \ /F i| gugԧonmEdXREBX-s(hJ{ PkVp&b:p ƷQa$>)@p .g ked RU =kAVVUxv`! -0G `'>g0& > &0k Aꖎ œP`POw$\.6Ek& d.~[ h`- ̬^-`~⧾~. Nz^AX MP G2 G]^N_ph`AA~ OL`)gv6-0>|P%Ptv F~Kp ¾[O onaP &>Q3_ - 󝽘#P. kP& g13n^/ 'QgP| &i0 /.~!He>ߑ``EA┎KPאp_HO o GCޢ Q3R@әzpP &`pF ^ϒP6x^P__N#@O@ DPB >QD ]TĘ9sPAQH%MDR!. RL5m*x0ѸTPE2`S M>DBQ7UVSc<VWeJ5P:$WD_-9n^)W5 $k &ZXd 3"2eΝg[ MKWͧ]e,h75apܠз{oU;ȝ&>t^nN]ҷj]nU:˭ng{{[ѝh@o}%%?%4Db.AerG=Сͺl 7 cCGDѡZRDDc oDpQƮh̎G#dLGDF$- #H)7_rC%bK lKM<87Ӕ,9?5_b9,Yt%MAez'΁\8GPͩ%!kE̔NRKr =lJTsU/4Tב"<b%P'[]$UgElTbԨ?˜t - Sq 2ntѢsG$)6Uw!wpt'V~c P|/?YNi6(9[6He~ g"e.!v^ b;rpAq zڋ=|&ԟM=M<@b.%&t$Y)L@ni{{ kzϦڰ{GMnƻ´yj=1dE@gGbk+ D0nI (?npA $l' @;}Uem* 6^A A &ӣ?B*8y$FUm_D.Ez~L=,d؇Pl@ -!qY=&`"ABb#[pj% j Y>،>~CpMO51NVUfF>ВD`-kZc!~>A9in"JǦIRfx'hf\"oiS[Um_m&5k2Us9!:BBh:Ž :tY bwF9l$gv.ybpT \k`49hftٱ. $Xs>LUOHP'7P\#gT6uy$"VGWi; sD{;V:\Ě1R(IhK&7(Bx=Adw+/f/>Aڮo:f,v M* /_O=!])Ф1{y3T[/BEfS5dd&cw,44əv1%:/1 e)3zn% 1 D!]+:@,;")) !$"4#D$T%d&A !}((`S 33D4T5d6t789:;<49@ACR7;𭓈ߋ\A I )P5;Az` s9GÊgDϰD?@_@CQԈA=X?ӈV\EDyT&SDḤI9TaT?ԈlH$Ty0C 9(Fl -u‚Fv w< n O2|GH܋ x;$Bh< xH \Pm|ŀ+Љ{,q,ȃ(I\ƹH^t SX6GyIl XB@-i?ID$ əlڧǟ$ ̚XJ ƒ ,p2]IJlHTE\|Ƥ ԇ}LHwG>L lJyԞI!5|!+@,_(Cv@ 4 ʤk#G0Ǎ JJxΊ(ݔ7p*rmwyb(}kÐzt ?lKANd΅ͩQӜ[iZ t_O OSz(l(bj w\z04K\K % 6`JSX=u-O݌ }`mX~XA&ig]Ɍ|s-|g]$U`^mVypa~dpSP3EޠM@t.(F`4"3z `XχT6Վ}^W^8`XdPDdRU\(/meVV5ϖ-eIQUPe(mOegPU4{PZQnZee>&{ͳ08aQBэi+Rb_*cUPP%c=LUc~`jU6u9.:6]mWU[a-=yU `MTV]xfn2t^Q -߭ZdlW1%>)/kp&ϩKͨ^ќS抴UeE1KK(5Fˆؗ\ ^ʶ ފT~œ*'668![)lX̪tmhz-Bpv90`lKxNJN iMIt1pY K"4I򶉳 C)Xcm [YKLb>& v;&81m OtPxLmokqN PyFP"yІ= /Kh'86iɰۅfqpq5 \͙\--ֳ '(8BK([ O}H4Nc gR@rfoGL`v esdfIpmtyHnWf}v&W:~kkP}ym^`g)jPrJA?q|Fnb#C]8 YeV}莏udlkkw`WM@W&-,hk =:ZOkU$u8o@ n\wXtm tjgψz@&h(xo  (h&H[V`teogm2d^VҘ M\r Wo.6R> wʳ!zO@w&pI:Զ H&N.,Xp&D1x )\ƌ7r#Ȑ,i$ʔ*5Z+gf×/&pIRN|Ӊ滞ӹP|9W}HW1,kY\vFHp=.V݌ QB'Q&9,f89B-eiub&%OpiQXpBW%qmʡlW:~]I^_;]u oy2LԱr8ΛĵN*7m[ U#`eƻUz caj"p a& BH$ E,\l8m:r36yNU_A,/9T+(>Hxb/-$Z"BUV)̈A:TB 5$c]k"/uTO/fh^ ZjRܖ!RpnLdMJZUOM¹;;ɳFN3oSDOVfd*ҠyUrp e׫ a)Ą肩J Š{Z`B=HIসU뮔cA2T„%{gln^d-rpk;q.?9l) ]$>~= M8p mWO 0fAMq] .[!y05J3SI%Os8<wx^,`HP H+3rQ=̱A᫿>n(% pBL[pm={ꀇԃ]b+#0> (?~ B! T|L,>H`:jmÜ Ԅ PH?ՂiLIbAa%x dy@1$\E-Vc8F@F#E0}uF`yP%~{fТAp?p%ZЪԃ _b:q&yPXIt>i4C#_l[atLᨑlt<%͢',06k٢80#޻ɾ\p@t"C!JHjQ!{|&\ Aэ7^Xb0 ŐGЀB.jݜ0ߒd4yfA 4doCU;GCzXi੍B0m1 %<[$}kO^KvnFh"9c儍azJ80S` Y.dC$o2-u ѭLf\@L# Ѓ >P*`#UP#~{/ ÿHZ=d44Ch+\V _C> `rpğC6HQ^ɘI^%OzXC, Y^M~]@9 :x|x|=>\YW4]<[muW__0܉^ Yցфف T= ޥQ Tb]FCX˽mW H/1$ I<`'mTCB$H_ FN&:";,h.@@R}[oAl`8G59O"4fZHh',06vDkaXY:p#HQa82΁&E=l<J(Q^@dGT[}ĢlRdoY,SbkiB~$(GBIJ>Bd^L)[ #< _I``#H$$Zd YI>&#n!B9^ԁ?"O"y@xOfdG W.Q/ކ1E>O XVƥp%\TY d%AN6лC6\ZF]D96IVL4;%HL!^ڍ& ,&J<=A# S/pbOZ``fC)KB(S)D)+C)C)`_(\^!b(=5 )L=g60j>!$Oe8-ebb %I\uǡ>[тZz^5(=_ h)eļgIMΑnT9ZFI+ Nف6T tNV`tv_t:X5\>6ZDJ ڈ}舅D͑ޝ%0hhHd-ʥf#h򃂕8ܬAB()UXGa)--^O>gBjј)HC!a}`lB#B)5È*X]VX\uޞ֪؉yGMM fZ`(d" 6gfJD+HA \k*J&c >iZj*v>akFDcKZg\G$5L'߹KBogZo**- fo t^C>fOB!Ix֬>+lWAĚ;OǨF4he2- mz)\(Jm/`Zmh^NAΞ2mm"GH$mb.BT>od:化D=^:A'Vo^tld¤~9G|XMSB#_&;*#*anHԭ-G$|'_'kSvBLA|*|-tQ7,9SCuͪ  &GD |Y/0<ܔ+O5`r@Bp~ TJHp6 Ăy$D2KQIĐ$s%&ߝ'rH2ϤxD;$'0*p H/0?㿕zC9@}O E $|JIZ @0 mSp9*h>k1* GB'rOtKC*GI4BFltGw>hrGM4=4Fh19I H˰&Cu+46C7*KMʘWH $t B'@XDAUXgAH3]C{}?YBbQp!PCFS4GB?j'thwt*4Kq+tGBSo2 w&&v*6=vQqS4NwLtlTtJ~`Bj屨oG|BoF-Z[2;t\-O90!h/Vb>]G;3 bcI P@<}IaO8-|EBCG9|B'Ktt9,?'HrK _ptH68pxN4=,KJo4RHj6UjV2!o#2[2G$L 7[[w/5$A @; YU OvO}3 b=*ɅB,4I}͙fqxH'tovHoMŶKssrt4l^:_5= Q>i Sq?7u_d<`FFԃpB[[S5/C6U ;Xg7/J= A{>l@?R=Ѓ53xL4+8HN9q4ijxW<*ĸK2?9û3B}B+H|ğ>,R)`'9GytœCct8VK.l9FV;//u-$aHBh|@5 *kIB>GSk+Sg&v++zCyA1~Skslc~)1H7R}9G0OҚRk?cRS73(swT'ς4`̈b>44?p]xWizOܶI6[mvil1k;@ *kU9~l09U0OrƂYthBXNԈE7qԩ?:'XD&):FMHh@'kW_z6̓*][lug܄M]}񓷎^=/__~ ~/a)Sws=Sz޹ mFMΣ}tӫo,ױc>tđUrK9xezGѧٓhO>~}^?~C?ʩp!?\7"P 9p9yyPD1? pQ>NPDyGk' DPXJ'k(wdŠR-E.9zArrNs t;'tQLJdJ?%qj'?ΝLD!G\"fAl&pRE NUUSU" ?BoZXհ9b9\ EԻrfV4qbAa=,U(_FZVk#OXC[rʶCs*s4,y ;E U 96s  sȜ0.ʹ#hV6+n 6g૤ܯ̤O܄3ov%*an#2H se}RTza!~/^ kLx!H.ga:%+y A{צ۾ a:Oh"&06.nT`:axJ}WDrқJ&w`]=io*o6rT.G{rmS)M &tQgS1G~K.gGRT@f)u]s!~t'!,lB4Qlw-){0{ZԺ>VOo?A BƷ51|leskh^RB)?< hW|,GvA #󸳤B YƐ ґtiT# XMDtU+w)R}8";u(ȋE.1 (Е|)RS;H(SP"<)k /Y6ҨJ1A3:=*kգD zyB/'E=S IZCbA!UC(Q>V[Չ;V٢r%GNa]dWڵ % بNP~C)PC`KpW#b@2h!Hp0@ Cx"I9Ɓc=CVR>@mb@wFYU`]N܁Y@"k&/Na6\ `h 80QA!$E2q%x3!gwR{YO@﵃#d l)b Q821ID -hr@@90wdՏr3B h0?|.5~83|J `-d$G26qqh"˘>X ڏ!ns2QdhVDY xCN&QeC񶍺j^gL\wAq$c>䦷y'ܗ&T 8w|o7W~>wy}d-@? գ-HApi? :b[ )gy@0,7G82aУF= fG˜0!J,Эn.4.!/*aO&05l.:o. @P.aJpaƁ.! \Fc)oFСcA !4 jJKx@%XAȈ,l>BjA.n!*ԏB~N4`ی֜!' ! /,6Vl4B&2A>q.0!4!.a ,FopBܸ]P/+o Qc!/ϲ q R,J qp!.AP(ʁ00@1L0 Nˋ1'-H, "7&N/ " ܚ"rNO o$oYx"iǡ"kg/] !I%l 9j渤bJ bmc*KQ'!\K'Bp!Ҳն hA0@pN -pMr#Lj2.rRHm"lpnDL.#'nV"4 p5 .\nH7M'ErK2a.a5^2RP RUH䡾G<%$*[+#*L0+/! ôO /+`!`1. ("."K0m"΂f0\pA4$"#,o9%0&Uf2l1^RPLROrBNoh e$ #Az y\& QP1dbJBqjK,d4!K!Z1"&@L"T086PbPNSNI2"Rp0OAL RUQTb 5NP=&PO,e;hwnJ@Ō`B<* kCRB #aTXXfl+a Yuzg~*F<(@W*EHAU#vaEUydp5^W[;Hd;Ӄ* +*!NZ v<IƪBYQ+` I6IVKr9hu +2k'b vb+\sg^U@F+xBVmU`}!FVe_^9_Yuhi b{f(2)NUyVvI\O -]3bF'HMl7̶lVOg7dcP`'^@ƋCP3fגX6 J6?5QY?9'j˗j#ŧ^@ ($$kkzܧj@Oj$ZiB$yIØ> ;]&d:1;4>;K*]@nS6ztjAt9N O[@Ps{| tߑ` 2q {)K yP@^$`ąb.L$o T(/{b @=o";!a TKv[<3Dq {/0Tѿ\o|^a@C~Q@|a˱T|"`}= nrj` f- !"=!P=+,  PIz\ny ӹc|Ǎ{<>d`!)Ǒ ?)bm.щ!@!'_ҹH"d)_!DC;`! S[vw]ͫ%$ e[d$׿׃}]@.`ܳ jk-ͰB; H"be`!`Ịc"2͋ ؏/ D1烇13$y5pEcCTe g-Q0J t*$>iֈg5*?>Xh喹<M2 nŌ#"?3f _K4Ff$ FՇ{AA 5j۾]/p ŋ.bc K-$ ?۸QRXIW3`|Q; XPI֢05(L1F2\.a>mP ^(_^Knt8]4s v  6u[C/H xwg>zs/.` .N=UC@`]CTW{1_}'=< =D a $ L1e;DٓH^;áz3O4SK"S2@"SbW1^cUIh.U#ka  %Uu)k<>'^S V\əgGi=\.HFFa'jGD,0q63v0cH`4F,C@ijE&?*G>q15VKcR=pcM3/U<FDE aXr҇aE"1 Y P6Uq͏?u4IAu*Kɠ= OlXΤÏr[_~'=Ypw( u4.ϨV j0,^pfKz Sʏ}˓P~~IK1 -K?7d YխI\QMB؅' /EiiE!/y[8f#dj H igŸ6.PN>ޠ HD` H5@~H5|PE T3D`T7Bm4{ 66hj+}1dQa( `/<|Tmbb6ƕQS# A}nBIx{ (eH0F Y$B(B b؀*jM. Saox'_t Xb 1%ts5abAԬ5)a9jb77Ϲg<{A xʳ9ai a]oO{jyG@P3'CBłTgaL&jt̴A1 yb8M1DK_Ce HZԚ* &Ӡ NZ0CV TjPT6%) j40@2ÊִuZ hWk`Ҵp;9ם5m[Ql8U+K`DXt՞I%)Sçb02Y; 'Ww,V$AI?J+[$46)G Î̕=(YG*BE%pxDdR"jY3^@:T;Xv>h`'2_h"En%X@J2x~ec!+H"yK1a}@0\F11b."\=02# 0آyf帩+Y߰e\pjq2_PR')Yb <ȱw%h '%-j0:ԐP9cys h/F ?}a]%/SR)骬W(ΫQOOK:Pϊ1Ҷ.7 m ñ x1  0E2ޒy\65|hpfn㙜(cr/:_m?|XyToĬ6ot6TwQ-#ZPc^ˎjݞb~}$:ENl;|.Ќgu'᳴vݞx'ǧ֌6! c!99\E=Nԫ~o_~o~W}, 33Ǽ;b(?O_K?ԟk?߾?|7'T7GtvT rl (Y7O@C hM(hyE8Tȁ!H%(O#h)Մ+/y 3H:&59B=7tz?(CHEhGIKȄ6;_images/regridding2.png0000664000175000017500000012224114713446504015576 0ustar jfpiollejfpiollePNG  IHDR) IDATx^'߫(b PDP(v^ bWj,QAQ{41DFwgwg..{wv?Ꚓ& D"jd&5D"H@K@MH@$  Ԕjj:eD"H@MրH@$  Ԕjj:eD"H@MրH@$  Ԕjj:eD"H@MրH@$  Ԕjj:eD"H@MրH@$  Ԕjj:eD"H `:uHV$  D/Զn4iZjzۙg.r5"H@$Ј%гgO#޽{iӦ9Dj:t" D+6H=Ӫ[nj֬YN^4`;ѣ"ND"Kan:~2do5f5`5yd}1J'"+ P"O]V) :12,H?5\Sm?ΥI@pS" D"$`K"=W$  H |r[BGD)mʔ)jNЬD?U?O%7;YJO"@ $Owyjw:bs窵^[*P9`+$E" śoF^￯^yϫ?jS}Q;v`s;&XSHXb\A4Lz!v۩m۪f͚6۬  4B |73PVmڴ'L4H+9o2jH [;7 0c `d"@裏ԣ>fϞ PjvS[mX l[& d-bƍ|Iշo_Vm&(YF6`FH e T3~w_1(@lH@$Lkp%eM-V(/!h\@;Aϟ:u>\&`5  J@^{53 ěr!]v?aw?s,(7.E, \IMk@D|bDv-hN;픨/`+<(D"%`@#z|:y"ܑ͛7$ lgH D'L[^gϞjM7U믿~ ލ3gsdW['P/(Д[EuՌ_u֚iI J@s'# BO :I7|{"%Qgn\lvrD" x=n:JuM|rKI@-nH#~a{C^JLlZ$} lTչsgnõ?E{C͈G$Pp PJZy/T'XS@mIM?SOL'xg}jEln"gX|s&# d&V?f ?7#+ȏƒՃLl;C?|9l)]$P6=t@۪_5IWX]wݚ߰u[6c2JꫯCLWogv Hz,zR'p-HM?tzl:K,QM6ձBҊ+X>0\cj$0C6bu=j#UՑ^z饚V=xx~o?mY/hZ?N6mt=-Z:"=L9K&b,lB*%||˗/W]wXc"WV N.9>\4*Փc̯&ML",^!Y ȗ {gju˖-S{キoWecgƑx% V#sOZRƍ`9ԩSW\kӧOnZ@MH@&Q9E]$V9E~5i#i0[o h!IS J@VR^{moTVԫx .T_l/Sf^!t<`+kPRޅ,I}ʆDl˖-H0J+؊=?2ᆱk͜9[Rx3Ls&.]԰Dj1oF AZ% Vհd_Hcx h̷b S#9e/kQ?ԑG)qSl%HɓoT[LIM7T:bjt#D@aH ]U  `7 lB\ W~fȉŅDϟ $G}݋i!d-[y7Xnfm~T%7tZs5szh!W޽.*-ؒɯwi)QkΜ9qPt`Y `#7Llx j QScUw}w0D3xF=.vgOu0! `as8; ,k z6lկ~墻F݇[N[6*Ә~:]!A?Y|jѩ3'VOk`c\{j7סIf$l>56w,TOlvf٘`/˺Z)sOl1cTNROv, ظ%؜~&;`K,bv fl{=5c A ;*Io] `c, ̝f`KlI:i-W/N lL?Xt!0hH>f 6F}6.& g}> K [ldYjɷrLY`y䭷ުSJ)LaPf 6/|¾eU+FBd[|$qͲ l-Zؒo{`c}!O|.rf6{i%Oܑ/1Ebtg"k\IR)6w,TO~fjK7 >￯s|Vr/#{Ѱ]7t-M*`s'BTKtu]: ~3|f;fl[ـly'|5`sl .sI+Qz^(*r^PKI܍d=̢$6WF`cS{ 4(fYm W_}U%! kɲP= ؈Otfu?RNف/P\ 6i6m 7ܠڵky?`,7ez*:1Z-]T35Ei[2HTaQcvA l$`=_s5%pH\n!d =QO-I-5H9R]q:HvԢEFK;sL]svZfh$Pg&MR@uQ:am W_Fa=wyG=ڤIT۶muʵ6C$sӝM6|:3 BƼ0HN9)z}[mW-[4|F4GL[KcleLYgUG}@®e8`R<:ts:4fm6`KS;Vi Ɣ+|%8Tn|Ҽysi$ 8cbEG3p\aHN{5jT*]̢Ȩi{"WK*Njrfm>Ӈ(@)H~[JyEkw5;sS[nQ[o] lB`K| Q@b|Un`s'BlN&,$Zr”BA (HNҕZW\-$P{ɲP=%{Y@pocMYc5uJM4jkǥ)2-+Vϟ(WK]sk@`/$EK/4onZ*la_~`+ߜYl|0+adDà 6#e\+ E.DKldYl-hpj$&jV}l Yl2"I`KؘnIE#, Iw6{Yʸ}D[:VZ-B'?,6wFOhm{O2x&>Cj+oÚ[`ULlKJ[ J=A!ӸM-`[h1cfD ez 6N~Ύ@]G?`s ls֬YWgqFlIi釴rAM#N lif (/s+]kllAkERj~[ }ho|UmM7!LGMMMK`Ul6R*54Ƌ/qիoԆnt /PùhlwT"3E~Gl N-\F{=LG nZkg\`#3?@I&.Q 믿(MM-z)۵leB01g՘qq͵86z~41΋``s?"FXA揷~[g$}RZ[ղ5ߩ.H'HmliԦnڵk`izï` QW!n,^X͞=[}j6R]t0Lkm |g{GuH| (N{O.2C l&֛XV_*I Vk|ZtZ-`{8t8ޔ B܉ή'@ c-h=m<9)a=0.mo`Kؐ1u=XC[>S,XN;4E|7M/Qh׊Ɩ\$ΌMg޼y:eU'В}ذaYf.n`KXg&wH-?`c vmj6j/.XKys=Pw/>6fP +5p@',0{5=c lQ l|T|@6 #D!Hmf{(޲GͱYOXB=vaQ?EtAlҾ}X`` Z85W$EH=Ӛf 2)f&²@ ,N3®slajAO쾜,46̠<&;i$J- {+`{7u72[4i$ e lĵiSd~jQ`c!묳:16uh(}C&h^ز6|7|I*y| Q0%KF=N:iRHkf!6d׹--1cƌMMama"W&NA E_l5:l'VsEV._}!&h՚[X6L>|/1\f^ѭ,k [67ݝ;Uj|w}b-0гgOg#%ij ܫ뮻NuYyN;8fϬ?wy:337aڵ>}>@'i$HyF>4Z 3lq=ęPӛ% ʣX<^{MW&ymʔ)jblTЭ10Qx,U~$ CE+|km$q+/>xQͣy:/R'C\sM_"PF {`ɇGG 4[F%̯Z9]b\-?jܸqO>;Zj͒F=1}[`+ Vk`?2/_ܷF51 el<33<\~M-?`3 Q Vn) ZtVۭ[V9i;CC\sZH-` |p נO  `[4jȐ!l1&/ ͰDcFc#GoS{キfO#Wڨkja}! `10B [#V_fa_pab J$VXwlTkq?뭷^)`F# +<4}[vb}uaZF_u)Y-_`ݻw) qؒ>_TaZ$,Ip4Z6֐rHَV-[yg- l6zꩫ#&4]r-U֭um7< +N;/lEG`/ƒ+ofGe E6):9樣`$Ҽe4K.DW0œ[<.66#ȑ#Wml*́[忻4`{+K֑x[[<.66~](4wʕj֬Yj7V{s IDAT=zHdZInfĆ9z, &>U;-#?tu]WN&1 %?$`젃qlM621Byb9l1W۲E[oU]}U 8|ǚ)A4׀{N;MOgh_`#W$c" vkѯ`+ _F1/첪E-؊lH;p-/[}`.Rܑ}hJE5HWkql~2US$k`#]vjw.WsK lf{OL-^X'` YMU.*-Z[xwBtMի|jر P9C>Zr^'>lq+qtCMwq%W6WZ[]t2a&$nҤIaCe-Pؠ.kh8ughrQ~&#6Gp'Tc9 qEM@w0bU2ɓ'ѣGkhYhlaY|l%T &ne6@,[Lh<0l6Eaf-^J`#ԩSuP%C^N8A3g*̔hrd>묳V}ȳgZ H4=>I&RL.)'nIL@Mb~dL]tZՋ/<[o c[-J >\ALH$wM36"û[#sJR`5f Zi'6x>Z1jĉz-  P 5aOt6`"q,#~'sycԩWvZdx$>@df|,ԯZo^Z"1+&L@3̔jٲe`7n^4H@¤ PA>5kVؠ"6gcA 1 +vqiKBtFHXalla?[nQӟr5o @̼):!|s9UVaS+I$cȟ F)*r)Bza3NNh`46`.]G'o6#M90-T.bQl&(h ߫ ^S0k"e3:u`wV&xo],)~-%ɓj/:a׿nlؠil`]еkWmrĄS la :4|fh1>A$i'Z &˼ sQXlwk7| D(-1S`byle6F(\i(%M6M˚i1x6`m2p@$E@ǬGV^x`TncєDGCl W͒lTO7l3Y@rs5E[ÏHݬY'fcfw[śв GСCZ~K l| &z}ћ<`@`sAPa & nGldĞvDHhfF(r4.̠aDmb~,1y Ŀf|lGLihY+`x26Hk~hbdco 4gQƉ `.ZAsab`k\;df]52I,-JUn|H;Wsc`Ka-HѮ`dq|&1AT 㯣;>]$dۆ ovWҀ63nB`tbǶzFkQc;K sϡL@Ú[{M[`#`s̍0,w_)M -EGCaKlGrEVW\q3cz6*6}65w66Č_u3&T̖PI LL*5øx6&)SXzLJL\dϼ`Q|x9CpE˘0{ )k/vұKG\M_qceey=Ѡr5s|jfhnY_Sj`OS4LƓjra fM-3r"]y6| kc$,a46Lhf\ I͛7O ;c`b%`N)e>My4m5yHH{_j`I\JJ 2GXL_C`_#?#%Ŗ!a! E7Dh`; re4 W;4)rdJ&@|XA` ^Zk(յb\-&[V$"lA,TM߆w1XL,I<|}1C(d$~O6&&ؘ?}-HVsJ l8ɴA3idt e]Ъȷ&h7d B&}(@IM4rPĂ6=LhN$%GDv"> |HHf8a|s,XHB `ps-?R}I.Nb0q17lk+qěs;`o'OBD->qruᇧw4YSJ`#/"NSy)6yZ”H*r: 0}ENк0kL>T{{e3>6?`F-945)P =efV4SN28ށ59*16e!L9 WkHc u홃YaH\9l5y}V}n) Z,I^iq2%e?&؋ F0P "`lld`L?#Ijl1G'gUB5x1,~3Yz5bf4l-CWk)oZ %|噥66J4(jzGc`!>? o2g4/ S#$ ?`I;2tXF?`ÏM5lȘgOmHhl&Z$`#&,0@-!D1d%z6 ZM7zj,)%h2=8;cdaŏ s$>JC@3Ul)F % -&LM7/4# y6 zꥵP̀.`bц*ČHF`b!G%`ccHwڰ=4'i،2 Yc4]2zm$ҫo) o/ l8a8BP bĹ `c 0a~0,6s0Q}l" $ LWc\LJvfR$`' >yZ6 ,YZG|yy'fX|{9@f@!ć,bܭR)(͙3gթ,0h  pDA)$0)ɹƂ7@4@̝*( 1]>j.L>(ؕPM2 -b4f#yx"7QԄ83lydzDܹsaarPlKy0!hl~goLl'.e8Ӝ/(56Lo:y%W ;ޓy&wuϨ6un  hT(R6)fl&xdżXIut 6 pZ;pN@v1)0hqruyq6S16N3`L"\Z3uvtR h1cԝf6VoWƺb1cN?M#xT6Ac#O- ?<\ƺz4MJyVQ56|C$IkwQ6~$-1ljK!N\k"fE(Q dkpZ4cNl)/vt'"di2)*SY;ﺵ6'w$cKkCwl!t NCہtl|OċHlO?ٝҘ nlqST`dIp;a˪e lFf;X4 ' !gΤ #mD1Z6I  B,/,6Fe6N#o$Ɔ ` 57 felfwP3iْ]{[&֛݊+aD&BgLY}We?\I`p-\^hYJd[1[َ lhI` #ҤB[`~&iHul5:E6DN 9~ hY IWٹImyLDepѼ)F|lizܭ,6w,TOE6#坐f6u6T|:!Z6{t.\q $IÚcF vNJi2Ra$jA` MeU+lY 3 a:abµ&vw)#ȧJ&.#6CŎX54g@|A (TyHM'1&,#( EVldYOG`Cz+Eʦ)*RF`CL B*ѻjqg<ܐGՆQ =a KIP]7<&W?P %6zG@9Ә’w$e6c^%H6*4Vj oO>d0bw-#]Yl}QEEk\gُ[Ylz˖-S2 Y"A6We`5HY4Shܜ42 PɕxK`#h A`r6&V3^`ctO2U^S5叠S(Vf`C۷q]elT>KfFYM01LsKK`;aqzQ'0agB[5Ujl-L+ YWHAJIk`%d޽Z`AP ?,+ xLفl IUԘ_pV lc#lb6ؼwi'6pL(@ N:Iy_@]rPH:l-?@Bn`/8\WԘwr !~fzNk`3>Bj-4 %lC%(y690وY Ia6T$ȬmFaqlM9?`OVFx\})3嘤qu] 1DPP+GyDe (Ca =smN:eP"eo)1N͛7O?]]r%Lì)dd0m©Ns|ǿד;҅6DfҴMoʹux[gʾaWW`3;}$<3~Hof>̈́}IKg,_31ky>D C]v՛z>ܱq'rv~嗁bA{Tfq|MFG´B~N[R!xu8EFX*8q7]e2EV#L^")" >É68>6ބ@0$ Ij?cP&?/ôM|Ih%\$VIHce6mLM{뮻;젳(0z|Gո-.ax0G8(<.<?[ߘ6۾}4[y1㮑8 őZ )+D<7c`slE؂/*#.IZ76H5ӶɳiӦ|mi׫vڕ`K6Dd+e66+@C/ 6zƭx("`&)_($1miɓբEt(cW`e) UD`#fqگlfW;[:xb5~x;# k JgH/#g )^w I$)6ә~lɵ ufhƇĩ tM+X`!Fc#!1E-]{`GBRN5dȐXZ@`OP&DbMKE{3HM9?pz*A# 7D-M`cL*&I?jtvlG}!8qkCDMqF;st61B.[:tni[p3[H|5@)5@vd\3_gϞ3?X$_fA/ A&~iG~K/Z &VhR=ڪ}A#hFƒ_c㘎 5[Yf*86| `bmZSmmE8Ds8pIK޾+]j*j 6RrV)xNPüI81vTT9gy[- IDATYYAbGvc98 D6@mС:K0*d}!s7L .L4af ÿQirx@hIZPSV5Id~\ce=n[5`#vϰF:|Q[Vu\e^f1洀 <,_C׿3`L>hMud꾗D6H?WnlkV ؘ/8y˘~#nY,AviiS5Բ?4"fdX1%84YmNջ™8/e_+N)-`;Ԙ1cԠA4$6׸ NHT`J&(ٌ8l|$ 6n"c070">l5rHwfdƆ Y۴J`Fy74 9B0r9, [L6uTM P܂}8jhX$Aqle!ظgѧR4JDTs tI͟?_pf;vbӼfڲyNvGj_w0ޙ3grH`A~icJ :Ť Ao߀W^y啡Z92,3 l6N|inlX`+t6 q-'I&ZbjNaـ2=4N#6qH-ƍ+ 5K=qXіlR^{m`-FN8A (c6gh&ۈoRjd1{~ $JL[v֬Y Hue) el\G}7jY9udjk {2&)"ޜIC?qMlӦMgtC+0l0]7̒/l6 s4 #dt=]vE?SOԳj4/hڬjs/f(uڲ6-uͺ&VKy/=S?¿ PCKqhf(. m h#~SjcC#&*]N3fP=zX(6>0Ra8Kq0h.mtRx?LR4?\7ЦZ@ke6sŊ@hۖ5qK.ο}N:4Z>+ fq=t^x:+yP]a  qLl`Lu6BY 8~11BO 0OV[H`R碩bb%&L8h ;r`%Ze l|f,Y3KZ(lE Gcasmyi09f\ skf8$C~Cf&E+ILcݴl:j_|qS~6zXy 69`l56ʽ/3$A4I ƚ$ݏmɼ.}#ٲ6И@=4F,`B=8Ac"3$洖-[Z]`q$*36LPVf@9Ͳg?œtS|PN@0 &32~H- ;}@^@kѾ*fN:$I_V`c>{=='4䍌80l<xgBbw`5ZZePw-/`2Ʋ\+V򌓍 (Ԇū6GCS}cR;묳4Q-R;B[!Fem۶D9 k>9ֈ1Ls40#L lTY{'\SiR&e6fx0wV >D/[y]'B)a606E6չsjs-Z6Dvtghk` 'Gq6}V6!ĊxD0tM@Zu%h򢼏ӌʐGƉֈ✐(kF&Y'$WV`K/+4&ͧ~ZgaҐ[Ru'}`kݺNX 9S+-LcツdcqH M xsMFŜU%[fm69hmPrI(/f-h GıyRhNVK'O&u$vF8n`#a`%քMƞ&X[ZDX/8C5e\1ml2_Sa%vM jc~ KDžrqj^MZ-Dzbm7sfA:X$#,aE]q`+9swaDE#V46،'"_C7MM*/[%UӨ–4 y! ́Av 7hQ5?qz6O-)5.XTC~7EaFٟlؾ $ho3\]٥-U/X l0W8ChB؆BEJRG1FSr\#kTV"0cb Už;υˆG4v6KY@ 2>0?ob.Ӈ/6,+'Ͱ瞉װ5;x;NƑLXI$v}w}ao*$\* g- ihgleSy8l~ ZH<` @{Uo aS|e]>)rt\8`ao"3[,YT.4N޴I6ɪH 1 q뭷^zR6 > pkS5$F8;mQ2>?uF{D`l|Mhf [#Q ۡ1r<9Y%Uyl^MccD7qFAl^N(&aluq,8>jPh}SGcOE`8P)HLGZc(1A `Z/m̼;' rXI~ӧ. D '& tW$0wneXkXlrGF7k*ɚ8Y87`Ty7q& _mhYkI0KšmarOFC_aɏlyhl"HQ M`⇃dIJ+o6-įMB˜vL$XEdD_X({6 :lLUW4GS[f_LzfjD9ONyi,>6XB6XfoB3|vQF&cI߂]4H4hXcZc6|7x=Y(1q8i/_y|a [ Fmm)ϜUkUJaEJsk:HZ`Q",6˹ %amӦMU.]t x_N"?fQ56Xm6LP6|0+OSv9DM7lZGy-ؗ/R7^36Vdcؘ,F J(*Y.B]&2&_Bd`l0]AE1E`l0'R^ӸU5~1 T\ܓW[-iײeKuawQ!nG`s'B +5 ،[Φr0"=j2QkӿPQЊl[d2E¶[/|'a\*Nꩱ:|E6j{ j="7]ϩ)`ꪫbuE6+H={lvl N-\F" yL-Lh|8h4r {,l] &.Bi?V^sc6")D93G63Ge~w: پQ|#5vϘ1CM:nLc3=4"ZS`_f2{ȑ#Eml3c b[>-2/=S4 * $6H$-RHxqB_}jrV+Wzユ>@?VpZv46~Y"O=TeVj^{Ēy P( -j`03 ,wsi%ѓ$&^a!٤(lelhwܪDl\Ru:w5H+$։ %5ueg1DuQ5v\5v`uO?N=P fq69\OY$l!+,1=UDKPm%U 5c?)ʌ?τAF6yw{Xm~HcWǏ־I6iuPzXUǝԜ{7 OǖUd6d.aHŒȁ/s] m G)>(qG[{wu"Nh%8#-ESmbUul&'/`cdxw*Ɔ|kP;ϏYWtM=vu9ja]wW~QJd{Z]{ԁT' ~!gb_;zmYZ} E\}hƏ_ `}u썍O 3>2S&f=@d#i؄ [A l 1>LWLZ681fh`_6\E/6NאH'{h` kdG?0y]|W^z2Թ* 9>D5**ÐtqB.21oh49s,R@b #;w͙Ո1R6 &@86M|XX_f@ #*9E6dkؑ~r5_@+:l~ lo nD(o6+#hP3򱕓[[jqlAI5`| 6%pbƹ'*߰"^zUYH"|r VGM rʔ):xm,)IrԐ~ɤur,*1nPap u;.f+xWިH).#+xuR|TS_#>褓N6)5|kQn@>0D4$TMc:I/"%0ř3gv±zXZM-dqM 8Pksŝl1N/'pBN+,6 c5`ʿ6ۄ1E=Hs`qMr=Sf/C y1Pew ԓO>}E)AKv\'x|[al6'9,ʜ62<:-&[}{_`M@kc4,ؒ} 9<ә [~#^{&VO;bae͛7ODzUJ⎘#yN9%ˬ ' k# jܹ(cČN 6 me8MZ71&>iѠCST~uA4h20cX^rG'đ)sDy2GuT!lqf{ЇzH![ldR<7av1c4bq٬*۶mȂW4dqǿGQAy6RuQK}@p`]70#pő.njI}ĉjĈn^x:E U&XEKzHڼ[FppUfC5~66.L$}ݧ:uꔻ-טLT-8CfށL /4E&n̛Spć^ IDAT>`ejZ[\u7 _?O #slq m =ܣMhiǃf17(R$v-iś?aNn'ޫC`,b<l&l .;lA"`3/4_]㘵ÀcKKe-x8Fe!"e7`V}Y6# vС& { $YZ6וɖ3?q(aƳ+VuZ68ј:d>OVR%b"9$@{D]|8!DTkf͚+E؊9'@PƌK&|)~.p€ レ%i qЄ M%b/i:Y5kcMDO\Qͥ4 >}asM&%ZoKG56X3hI|*6oZLҲ1fXhX[2ؙ,yKq+-T͕$ =zl %|=LD$B jO."RсuiY'n`cL)C׭ń|Lhf K~*جE~! 'ھ}f) 6 [X]6 kKٚ3U4`yu V"B3:v6ֲk-+sPe l/\g˸NؒJs?0Qɗ y6loPʀ2Cy7NT&q鍊nE6cqQ{рdh'S4A8D8!\oe645Ty=`"nI;Ce"\:j(P>fl6Ѵ"@ PaifYD`HL(5"dS^8YɂXdK=.[Y - I!Ҳ\Of]9B,fy;?YF66/ҰN(}EeӦM?q0;rH}ɢlaE![`K٦ϲq }yr]`fϒ>\ $]L;|>|fռ1ga&Ĥď$-"&HҳgϤnuVƩ HAb`[=]ys9G'(M;WlW[٬`c)OJ~сMaSXL ،p}3ukS`\7F8iklfBz}*b$m =JB ` P߳o6,fǵrJqW= ,Jp)rߓ[4EPaK li>LX_Ԡ@ij`IؐXoU 1H>4o&|t)ɉ;(WсwM/unI .yƚ_f`9Zr66iZA6d 6u.]]yMl%͖M&*7 ,e9Q sKT6ume62 LV2ڸH&1^tA9U`8p6Ei&^9" w1W]46[I:[`CYE##{iY‰l\K842C$Wf`Ip5861^'Ĝ1 aJƴO00Z|ҼXUl2m.ڵ f+`R li[|`C~饗LAXoUv`koKY lfLMjl0$w j95lITvML$,[Rf^E,,[}iRX(ek.=@扱eI.3!7*FP. ~-/q-!ZoFc 4| hg1e]F`Bʲ E6d BLZ y4C !fF(NJZف#FPcǎ&$-K`аJ` iixg;'*{جEBC=7/N,YT(آ~dW> @3gɕ[oe]T-tʹoe67D]w5q,`G˪$}k%+~`Q46ޙ,$dg رN,#P6ɰ1E 2D 4HS]7B,U5qDM̼Sv`3g3Ycb=\l\94u!xN: ?nl)KwLPY5آkllŊ@"ET4R4묳N eyЩL-[ 6`c<0$0jƵ#@d+;y8ˢ=?9 ѣG޽{k3` 6d֦MM8-c~$&. h-]TQTv kiС-[Mc3c&&I+[E[MpR->qɗFFΝ%6`slq5J|!'DmE6|'kp&#Tq䗪{Ҳ`)2lwxF,A<y[ncюM=#Uic" i676_"cSO=55f[ԯ 8$v?~`i6KҺjl%TB/ H2&} NUi?pu7'S`scYB##9AՍfaÆYCX5k6o%WUUc f16GVj 26 j.%מ}Y?4Fre%hy[;ޫW"Dg[3{Cf͚oP 6S2Lh63<3Mf9'Pƍӛl؆F3~:YgDU͘1C8j|d![t$e^8fuWjP^;Tm۶Uo}YoSw_,GOhaߖYHBq%%H8@mfzNL!*& װFfU2@KE 2&Z!Xw}wli51E,Ag G} fӻ⋭7ˠ9Sd}鸌c\qb/) ÂTo-h!5BH/Tט#!(\tE=]M|/k\l~hw-Zdu}؄ la{Qb-ߨQTE6ލ>EΣ>6R?$FKl6v`3^8ծ];ղe臤n:SSfB#l^!NNwFd2DiE6,)āRآH(,Noݿ={cIJr`Clp99 ^u"HzdſZjkJvp+L+T)o`^Q{74ǧH>Ԓ|#Nw\e6NFyYndK:}Q66;`* 6Ra`X$ mqiKjب?/nM3Fq>Ԋ,-`c#ﯫ'ie61mlQSZlv,E7EzsA/ߺ;%hẂvQk1Sݚ 80hl<͏8Z؈{ ȂApbŴffe6X*SL7|YQ5(sXkYYq02`+?F=Q&6paUcfԘw12-`# !i2Z;)mrqI}as٫0)`e6yuy'ͤj l AZ2Fc#ݶl:1`lAlfZo V=EKcM_z饪CK':6'b Jvj1y]e6H|l/f@wᕈ[6>+)rP`ll-|PZ6$2,39" /ͅ&Ebaf'x[ZF}D S 8UCIit6('~[4v`3T4/NW_}ΛIgGLA WwORmeZI5GƘ/\m扇/X;0fcie6:w:ߖ)6r-#lda!P+CPccp (-`O8 lAɞج*ՋX#kW9H;rP]ߑ0>gۜ_GRn Awq7bm>ڲ6ޘ9#DqB/~ZaTF I)M`ϟZnٳ̣lQWY[ĢQa#`s?G{wIMky^s$SӔEpsZYVld r|j- ``0xW!ڡIxv-:M\`dIj2`2a2L.ZSԜc#"&I&鍮 ^4el,p5CQ;v ?}WcG04m`y96){ XSHJ`Kwzg#㌚P.Z/@8:17#+DmYczWM=ШqLaZ&0vj)劌Io6z`6rK4k`#B*͑Fch[mUNZT/]h~-+`ٯ΂C)K-t 3=,EG}.ZkYCZT\&5qD}>b?' mt}GuY۰+}scMPiƔ6(wؑUM8ilQf=kY[SNe]LزHOdyo=vr`?`c,$,ҋ]\fIElK Sl~1x[o0$jy`n5B NYcBfo[{*E̚5K'G'={d I(1{MM;DsqӤIzI+CYZ9Y6lڴis1τjx0n4, ѫ/G_<&ʖ5YآxkVsi-Tcm v>\A'CNnB-Sw>F Z=ܣO㓆 }fygu`c@Gh1&yYK~)Ƥj?Az@AvCT5}lnes,9llRՂ z `Sli'2˖-Ӌ@'һwohe"c *M`6sh6?`:h6ɋ;oAZLjJH?R-_%6u_j0u]Ҕz``?T^6vgΜXK*/`cSA7qgՀ ! 0+: &^Ϋ lf-:  ƶmRM-O[>MUdDl6:HTkyZ8iՀ v$~>-(s$5/q#/`c&7?n8]1̔*QcpBڵkblG DVV4O6I DkkR|O-[`򼀍D#G5`:j1ĦFmryZ& s9-6:#Cخo"ŚE{bآ+ի9+f&t(N}v?y6J˔?dϠ@)JO9\{uA2lf A} hr'6 ?1tJ8 )ȊBwjevm`](1` J:mۗj!hX(&:j;il6RL#D۳P(Ȧ3cƌOg$&jNv<&$,_(|T)OM#݊bh>Hg&l`l`5M5Uu6!Ds%7h$+(SO= lSLQ:uqvqr^g1P-8)ZM8RNpS#fLl ,m?<1E֟#K"OS9h65 ͺCG?@÷B֜6&Ly"+{&5}82AFӧO:߄/Q7l`KmVwl6RZ+56:Y PT|&o`C*P`Z&9Sڄ 5hfh\7~TB'Ě lɠ&L@}Y?lSsk]c]5f~Y0z5{ 0#-s1Ĵqµil|X+[ pHfμנAp{zY#5措5D ~0&p w% XADUEA(bP0xAZ/(4UX5(L5Jb4dsf̜sN^k_14MM|'O8ᄴ8Ϋ*RW WeO{(n2kh[Yk8I',4%d9S wꩧջ>۠k FÀiee˖N,h!{"}};argĦOǖ=ْ' 2By՘|=t U З-֥m۶'x'bK yXŸ&^,`Æ I:غ`]yfQ5dv-Q bDw׈ׇijs IDAT]ve02황mBڮ eclGԷbf.:6yAlHlG XR |QvZ&63FA7]-c #Hd 3ӝ%bXN&%#֭[B[۳JxM[gm>w؈`(EG*Pnpr4mi2-oY]!K/4Yʝ9 #6nb1M6%)BRRq}WMH~[$S"GoBblhۣ_r16ijVţ"koŦP ūYӰ*yv[:Y..%o=xNS5{JG}HUc&V^;Ch9ɔl|]oAկ~UY7?v^p~ִ^Yr!W\d/ +E!Sr2$P'$"B,Cl,*m17 .8쳧͆ԒӜo}[i>&c{`C֜@<11FU~lƐn&hGΣZOhbԮ 5ąH?3j{}B[z #я~4l}w-R-꽐~Yh\*d`\6~ý뮻N|-l#SZ?yR:vjZ1F{x{^RRuK3`v4r&}M,v\7tS/bwܼysʅsl⪪%\0+㙤ChHj6/)+HdF=!YRdh7<4FJ9ٚGF61g?ZNk[$lx'ZVJTr7v*8߻ aFOWΝf!Q!t`.5!_ЫmisDԧ?E\_җ<0]غ;733 w]q Hf9s@ƀG 8P_]FEi$y;ߙJ[e4T~@[e*TNT4?9m6gEj㚲 6U{A^]WC n 1Q շEYmkַue<\t/|~djHrGAld\r%阗#k1O#{)GOLROySF~kLщ>6U'Dk'P5~}sSY6 (Xt!\jgxJ[(vő,vvK5 wd;\Y\Ñ)A),3TvS;wXO>Ƕ@,ŠBoO#UC 'S/~(lْNPXjUU3@LL#%gXZ݂& =gHo⪫Jf\[n-:TѦVr\2&Alckj$Úk=lS >G?QBm|l?Yh/yKSRvuO@[!O0kԎc,qԸ@b"|خXڠZ@Bs=8S{sKAl:w_xᇇrvَc"'lvzkScM,;u{キ8R٠>6_שFxؐE];\h@ao1SeӃG`o}[a7|sMr'>F+_JbWq?ފ b]u>b]<b65P1W"y[ޒYaJSȤiP{8FF=5k֤W}CJ?˗/O ڪtIݯX *Zbޜ#_o~.*X4&btYUOd>S|_u~^+8s5psr؟u~G.AnL>꫋fF,1.3A mF_>WI}x1UiH a2Vٛ*5b7o.T/>t47q9ɑ|׾6aޢxF|;}VTB l맯";qrPI}QJ?&}mZy7%O/3[?5뚟'?dy?Lg/| q26.\]{[:91"܅m|7֍yh\yT$}lv3eeE/ 9Sq)^ԇ237O|8VxHʥMC=T~i>8&NHx1SlܸwSݏ>1s7Vg!` aO)iEjqֱmCjI"r۾}{~sK-bI\_ܟQJJfzɥʈe"I>pCuY'?$Q7}M]6k3:Ȱf LZ1,}-et3ѹ&Q yp)5*~B9젃J}׼|& N^lYEHFqJ}PFr“/8Ӌ?山h3HZS9c`Fv޵I6)=> X:@]\XEp-* ˂oGqDƐ_* VjU;ѱ^\B ko03zQ'_|`M֞Nxak.$܋_$bgb{ޑg=Y<(Rw%Hݨfx U 6e%KV')Ž5Q*M<EnX"B$ J )7!)"e ~\ ݨjG|p"'?E²BE*Ls|[V5[o W$ I&2϶@[{XǓR1ۺuk5P]X?K=1F%FLIq&&AKlJHF*udhVncZBH҄ ߏ|#iH^ie3>S?Alcw &F0YbE"3$TgcXhC?W#SVJ?v4eqױu5EVJHv! _HDO֢"%$[8#! %Jnulgr&ǰwe%YJpG;aUG0M5=K; 4,$KONGQpaeVZ "'hYx x82$" ;R$f>jMAlݘ{aq Gk8:9;%u4I8 1pC:e7?8:ǒ22i~\,bE) sˮ@T\+9q!UԗӐB#a=Xb ܇vKrZHSʂnBzEAz0Imuтc'mw>o;\tX AfSdrak\܆w^{8}drP m۶-($;"\XyޯGb7a)RsoV =7ZꮾJJqTǶ#3f-Sڊk+[ť^=81cks=ӌKvun_  F0+͂ej`U8\WsTg2zbEQ)+x]#NSNKFJI?PH@`|  w͂ H1טXC3%PK#7rJ=ܓSHrTDezG'bɉQ24J]C,zTߵa˛quwnҳiѳ[_(qJ*>ϡcbB|s ,$d֭K:hI!RQAlgtS;Q)w%N|~Ef}[|b|L71tV³S\+З|>J\ƍ!6'PsME B5s5׸r4`A X{S  UF? ^ d5D{,p\$CUՠ:A0?}Ƒ9kbb OV Ouҡ:S X.i wʼnÑ1*3q;?q62s[1*Ѿ>1?\zN U/c \ 詥~BGXkbn\0t&"dQƆ<DwbD@l H{M몫kG`ʅޛ\ΑsrYgf.S *5#`!mWZ)\qe .AlO[8XRMS):8nȢO?=Ak9S غ1P^u IܛkL08gLXt}%eb*x≩(q@`bq<)*:뺽{k_Kb#dXc]όI"*=Z 0k]N,IDATڌ8|YT*WQ?IU*2qbV@ 0 xA"z_2Tad\;3)kdE @ @ps=bŊCG PؙBtS@ObDMJ!۷gu֒yN[9+L8⹁@ 0?\WcJgsE{,ċ}NA\Ną@ @ۘ@&)׌;Q]Gyf<1@qZ3+Laqo=6; |_ji"1@ P Rpχ[l)~bٲessv1@OiZ+bvtC'%Vck@ Als" .?af QAh w}wu(wIl'< SQ@ 0ئtg?TAPw=)ǍEl^{mCk׮2@HIO>y+ܹ^{n"p]V0. bk.>qԧDz3({. /@B -^R oˋM66>@=_W>N;4c@b N6gtz @`izClk֬I^J4-@ X ]v%yqZ@o-wəg|@ p@qmsLq2F.֭eq@ "pw/x R8ZҳI @ P %@ E s= @ @[@ "ݹ@ T@ hqI @wbD@ * V$@uwng@ bZ\@ ]غ;7ѳ@  U-. @ .AlݝY @*@ t)?m-IENDB`_images/regridding1.png0000664000175000017500000021206614713446466015611 0ustar jfpiollejfpiollePNG  IHDR` IDATx^|GY?E!P)*ň5@ H JQP@PA0)D MhAQ콡3Nv9{7y=g;3sO~ꚵQQQQQ`CJ QQQQQPO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[@QQQQO[ƁOg>ϗ|ɗyPM} րa{z׻ޠN'>Oήr|]Zך}ٗ}Lu@(w{vy y׻5-o٦SWwNw?#nk8t( ?e9AߚӀg'>=q13￯:(()Ѐ=If69cgG}gT@h<k@٣ٽu55(() 4{<|#g~=((7)ЀgoKէ(Ѐ-FI<s^ĨilhEg)x0>ٳlkhX xW{Hp{G<+6ArApSPwa>ͳ9N7~7f__Y痎[?Uz>3?sgҮ}9"XW.ewwyoM<6S__uE_Eϳ//.sֽgܫ/{g&WIiZXٰaH=x&Ϟ=}g}V =qȏH"Laʞ&0b `0{K f}phwy\ 4ޣl=lxv\З>˿w}|)OyJwi3t(`ٰMЀg* v0Qs99\;sv 'nvM/|}Nw˺//4m`,~vǖ~khX?O47}{ͥcO$lzڦl's.WL 򖷜~//-m`{ І;LW1eЇ>T.y[;>x|EWmF{޳ޮh;/zыJ%3%~ɗ|g7A/`|dv;yw{v]ԓ?*__[4B ? //fۿ]f=ꑏ|gvZiw@w #S[M^m O|b1!>O/@?hL6d,7sG~'S?S<9E3ƃX` x8H<@{&/o}[L,=E3nu[-XpyЃT@pОم^XHG3&*ڐ uGs` pbczo^WS!_Um|i7a^X8SFmd@ zˊYO<31ZhN~ xOM /bѢ{ozӛN=ԃ1sFрNA %2`Mٻ5U; kkFHh v+̙9 #4 c?ci#_ƚ?Xww ]|xh<@#/RyxB$((Dh9_pٟFץ] 4Shg'c7^5 DHh'օ(84Zh1}A@A؍o|4n$'=\P}1\F3|FI'}n̂ A'A #ъE<$H= 88+A=>& Iܕ<{|2^|9r% Fm0!$} arr-ar-}{KP|ϿB!}2Lh?4Z7XD a62ǒ!.mSۜ6|#`DŽd&V2Ƴuz׽ULm>yű OeA"RcXٱL6GS囿}OF~[=.hgO:餢! )'ј:kޝk@?;Ș|F֪5gU  IU$)ꈍ˾vʍgj46Eddn`NYgDّEAh9L^V** 3@Z30im wΏ菖*p`ޕ51vO{O(5Ϊhű`O,@m^]qXn|~c+Ҟlm*?+1d\G["v>.Qm\ЭןC|9 ?%SI<-~!woƼ->.HF@}@jp4V!ѮT ˎ'4M˶ѽ?m 0*E7Ye@T3 cx)U[4DG.TuGu%0}kB# f"2[ cx Pj*Ah^2p^#\Wksm4a/J:$Dٙmi7Y;g$FX7-jv4~ZwE[[gO۔d-"mk5{HJ$O$JfM,,W1< 6x-xE!ƯRԑBW ѓuC@mRK@\h_9'S$јܢ%j`2%/fMN`,a*X;U&z׻JDU&rbbL0jI nSaqa>cI:5YP?A{I/èĜML 6{^LZ[G_")3lfI0P;Yk[8r8|rnE݋YAS3##PiJHc pTurƘDS2i5Հg ScK8Dĥ q9c0.C5uiy0V U0_YbRS50x%h\* 0grerhihyWTl3h{䑀QmB? afao'y:+6%HdlOla6ITf=Buc ?<1sLNX0r~ 5hFNI{֖)OVD03*pqOZgO`{Y;Eԉ|X}И+1e}M'"єHEl`{ 4)9n*%{m3b;4A=H*:'46&ȦCc;s0wk#648ya{t{ cL`Q0k?!|`1s=sv `zgr*50&FB䘹 19dNexhVYW֑*LǷ*|I@u/d3umme/-).uHk' ' H$\¨0ReavO0@to~~g~0UHH&A,J5a4ZNLl](,[90B0j&xT-\=_h7??Sa]Qh |Х<#vjD`0$D EQ bN(xߘbD 1RCyL,(l>H=L0g#E>ZLlD>Fqg8wQ6tMmLwޡZuy9>HsZ <֢T ֐ﳦRrKhfĜC4[HmHflۜ6~m_ԵOf @W["&<cO9J0,2WogBX@ 4|8u 4"Nh %1]^%jhabjIH˘h?v8[}alih<{5v@AA$#ˬ7fF{!b{^ZmO![Xi<#\D#6 G 4ҷqjͨroCA C-o&}oD}cpDY6,Ea.H1o%, 0u%: E6>Ǿ@Ap4*m/q"h3¥_\I7`|Wzc[g¦ \|t[h\&YMHVX3/g*6A-={}$H˘ pr,FVWB 3ecmltXt!%׮ <4BH{0*>=Z L%<0K1lodh9FiJv =4dZ ̈́%uDѬ?MjM)UGHe+O `ڰ5$\1]iڮq+&(B@ cʺItd( P{0e]>/h^Xh׀ 51Gh'2eyo")D׀UmVTrhj7KTTlф SYwmCaʼnos C$PԼ&[s%D0n-P LoE?fޛc۔ZG[ag^hØEwx!A 3Y azc `yg&ձ=pk`Hsc@H?f YQ@ شm Ofu 1{vas{ն69S9NILJ]-#uY`c5I J5odagydOæ10䝬v6>J_0R+eݦ>"rߐ?GhK8ƺaj۪}U>oخw&τ6{Dڠn MϪUzma r0\D:=&aQrSٽ:5LM2W[ك|os*0&t3Pk_S1k LI=VL{25CnZQK}׼ݨټ mC ":emnb{k-TZP+9*c3dA_ǖs n^_Ʒļ6%=f׬ xjCRl{g/s"*]XVbcm=vyf5#f6ܱ_މZ&M&6a"h_1;L݇UګȈ֒s®_^QxWղ־B˶1~O%ʛZf]O xC:2CLIWCL{)C"tx` QD_|q0gg?K^ELAs)y3;%?v6r^ڇ6b[TmG"k[zU@dY xX Q (5YOILqT"CŘ ,Ko8GW IDAT5 N鮯jWfbx? Ν xFmĉi-˛3bvc*ѧh:B}FuM"e:I24hIxT߹۸5't!c>5]6ubc/h"m6h4k* xFмm8fpsْ8*Y:n^@ xhf;5TPVNh$cK7Js_sрg6H)3ݘx73bh;Cʸ i;*s\whyAXJW}UT<4m]Hָׯ<ۚm3v xFmG+}ߧ8b))8ͱR}fpcVCMdJD} p.RB)okRiL>}* Hݞo3{<# x$9.a~kvqN;ɓ 1CCgS3d@Fcr4_3URQ!?8(%n9>_XM:<#P4R:p2F9 +u ^4G"DZju!m@bv%׿LeLq8BSO-A k;51 xFxc@%xĿ nO2v>ʘ|Ni4)ɨ}EBV0p)\&@B;j{j7y Qmhsw?Y*ؼj6YL<#ۀgz1qe.k^@)5CML$?ygy˿'a>Pm G?%Uu<=%[mՌBR_(/&hGK +};T؀ xFHDyf[r0f1?R9GwQa근-:Oo= O(9pg\_+< {Z`{71' xFm#@%l#  .`?}v'n~Ϯwr]` bХfS$ȗ:w6|-'2g~ჴIBmNu_usGqy8uK y\oozб<## 40 &*˚p׹;KAL21D@ioo$c4mҸ[<&8Xi_??)OyJ%ȸhRv!v1IV% =P@i<}{71' xF瑮kINL+dcf*PסMd1 <0g >eqdJC,f•]C*5H\h;eD12274s6C 滏}cTiH֥d޷LԀgH"0w &7Ia^xaaJ;r, <S&(?Xm4fԂS#NBNءI]][TNAw1h6$i]O4m4ڤ\<#6#QLkx3Hdܻ͇qݭDǹ]<5ymY\h, Si'2W-oo|ַ.ei^r˘oRhvj51 xFmMH('M6)o4|䃨`p%̜ 1ay~NExRM!b̑Cs]'Z'{PruYa um)#XA=V ׀g6A~f'tRus%LJKzcS, 뫿gWշn}\ƍEmW!yXm4?UPx{[*dctL:lE2[ -׷%zs9gxЇ>tH4(:M<l?]Z%2r k3b "F4}V}W~ea94^LG~GfGuT9'L~ZIeS7R/|a12>/gtZ{0LMaگx+J$PEB9 a͖۬@ ՞*Nkg{DC8)h:Si<1>1*ݷ|3ЀgV|$&#Ngs'ъHBi ||7N}{%!~D٩L{r-+`Kp-9< VF28@:#KUoo-&hu>߻!'Iyk^Zǎ5A  0l>̬ 0>$B2wFRlޭC6Eƴc0fۼrO+8lNǝt}Z  oxGT.>5"[LEso@(!Z6rw7A<##` mrv# }}T% f!0p$[yNƳ-I>s,_iaZ !~f w(~!fmܢ"js店Zn<#(׀gV|$OS*IZ8g1'>av߽5^$D^" >l[LL+_)R;Ĝ%B ?N9F^m>эnT &y7$au^ U%c/oL_ZDt*>iO+J|):U_>N|Vt51 xFmG81h?(_#5hهx ^oo4|7~"vN6l5̛>ƒ qԋVT&;A .>qІvO#;v^yψh3h+>1L$:l7LmȬ__4c\xKG}Ne6~GbBz_{TDd>{KI1Rnv{S%[1|n`d勢%oҿ16A<## SL`*Ƶ[jGLiQ8+ˊӵCB ¸]*{(cJŊRv{v0ѷ0OAkBn~omXh3 xFmG6lRpxH4$lՌa>8CHԞ='ŗUf/1pc\|Oۺa"}cSBs t>j&yv ;"Hhal~p&̰3*\%îCǴgO 0 ;0H㬁Kd<r=SD{J*tl<;FjyD\F"bZoi)Z⳨a #]&@ l`~Lm. ϼ1S}VLKo J< ,~Zn@ޚYM I{ʹK4'>%x+/S٪}0i<#f-i3 \w|wc Qa$\ڧK16cn0@DIu/c,sWD vh2;3yȜ3(m{ :yl{k3z xFmGyHsl}%_5xawAmzS~%6W8%\04,uwA)ZXrk1֓S\)s6Z]&cbiIvN@SayƜVoG97ADsl 1MJ^-Cȝ|Ga_VZAHַ1!h sLx?zDۙnc=$!_W/\1Iv!IWwgB|$(DKjIv٦k3 xFmG`֒&a '93T_B(R@`˜/ˋ9N!$Mn˜s%Si;5g@,vǖ9DUCC{} cWO^*VUSU'˿\ ugLmߧ:!K1uSg?Esf:6څ~u߲ '֌cӕw⧚4 xPsỌ݉ 0|˷eLRqg1Ղ1;xI m~ʻ=ݜ=U-[7B*v$䩤J }&VpȺp toC<iюe$3796|isϐрg)*ad@ /,$&SRjtRTn .E5܌i~~=?BrR-}4%E:v70q)zq<5}X->ղEmJOu@DU޷̳!zC R6lW"|qk|_5ʔž,6%xOʾ_ILh<"=3a-FID1=uɞ'<WVܪ%W}]s߁'tMj~(XĉhaL1XO|Lm#V=Yd_p%yOّh60>%GٗDsM)u-3 f9*pH+cc|47"];мOՀJu>70=uqNI>`]a<-qh1ʉ{3Dcc$\ЊD9NAvBk/zEƿD!$h6vE+um 9(ʎȣ K!oNZbޤ[m< Y$+W*=&* Wo_rW4?H/N*>1y2Ci< IF#1YZvC_Dh>%\RYf|O$a#gLxWbDh<딗Wݙ#ю  !R}/ @XfȲ񅸚{xeݲ:h v*E7sT X1QDz7&miݵ#Ժ盋vVg%>㷟h}{eEȱ0i+s;sxv21wF[[ hLlʅ+7K~2S"GH 01,>Cn|us5$&^u"<0\v xFP- @bNv'\"iΉ^;wZ6]xwLiMfvh^/w FRhr1$y-}/T_2O`U? `nSId[4nt,*[phA P׈3G$k9[}nɷ?2MUWU>ՉO4 xⶲAlؠפ0,,Hhʚn2R%{WLb 00 "ծߩ'M87yA IB-_ڧEeѢ؜s9r*~ ;L|4zJ9r#RUStxNI~׺"PuQEڌoӇMw¶d pu$Vu F!ZJhs))B܉VCÀjC!󈡊hӟDҷhMu@@)" b&9"Q3[I@'<ǧO)8 ~fgIig}v&ml˜8"-զ?ҕIF)y"ۺ„U4Sw0UǤ֎/ha1t;=Ą;}S[9/l몵)O-.;>i2=a3Augbaj<=W$UYˎq#紩\E}͘_̋K/:A S\}wdMqRߐI؂ >U]Q'Y]tET=I6Hv|#lgr/iH^|  2ifƜnݴDMBn(+)9zK_ZSU-6&#?Sx⇲$J HdȚLa;.ZS.E0;;L2ô${$'Mzm۸`/첒'Z MCpWm+E)*^DdDqHrNѷh̘{Lhv3I9 2®n07.`6"dS -oYXZCgRziWuPuY&=4h1Yչ@y糞pqTrH8η\ iITTǡ{hM*Qݑ6L14WՅ K%h"Px?z{[둹\dm&2-mƜ*eԁAZ xH{'o_i:ys-GGAml*lp94H)p:48r-Q6Db|$dO3|C *``S&;zGn8S1guVx$g#, xܳk3fghu P q1- (cF%zȿcr8km?A}Uy)b~#8 K0(^8/ɷ^>m\$83q>͢c?faʜA4>OI蹽ׯkXb>DDɾ{]wa]}Lo*&ب1eӺjE$zٜcCz7L\ F;Q^GDG8e _f2WƵM\srv"^˵A"{u#:`XɯC@h>z0 K|, BGt5߀gU,J0p4y l ~NHqL E YE*,͡d I xx^}VPnTwDJrv;*@agZl{+x8ꀻSg|8wGA/!*'e޽}<kb'(7yEe+Km pfG:5>d'*I"]&xa hn3n%kkJ zKIdK-ڍ!Mm捏B2:h BLpLY $ ɝ,:n" x1{Ma"hh:usziE_oFɤ4Xn\m6cdvL:f 9f/H_kWl[.9ײK~!orL uɤ̍ e:DS`8\wh"$e2Bn`}:' &P`l֎'H3(q3GѭbFHm[Zμ@&?Fjw_'(!}٩?f:2w*t }c7 C[KؔG #ϋj`@@T+QLnLX@mg]~݀g9m?ƦߖۂNH(f3PKh< :՚䠈aTA5^w ,&-@G`а o+iSWMQzX6L=|6;lJ)iBR~ _Xʦoa (|tTRG>H>ÔNh/}Pq~czQWadsw:t= B`kFnky֤c8Ex2+$@}+lYP;54Iu۷FӐ( ֓K W"gUmH{,K5_;EW-)N=f ^mv$ FimyDp %oc^u:.Qm2$ad8IIjc@8/a Ƿ@+fj Fi ai<*[ ]B:Lm}}LVhttꩧB@$/ܐw-{OȽeۘy#V?)6LI͉ڊIAiuه1b;e3ոjy. #/G P<36e#%$W{ItÌ8 cMHվZ{9@}"F#BH}%%cXw] WgCh(틖ESF<'aWJǬK@(Dt|rl͉oJ(C9'{܈6w̨12! SP ;|Pi/^ 4\ "u09A*7Z>rP_χ)ׁ}sֱL+bՀg[_Ὃ0ME/*ZssOzV_ɆՌe02'=ڍ PD C7VDb%w.Q;ޱ#cpRh$%!0BrhFU }}J۬g@aW' -L_b\v2>" c#Xce}twMM/kzSq1%Zua5nVO?m] xEޮYWyul;%b45>" [N_geSL8ThşilB%?rDNiO{ZmFhl/ MBL'f?pOnɽ9h-Ԏu0\jV{CGu!HHP}퐉XHƉqjgjaӒbN΁ cH1I$i+~ q>aꧩTlS\+kZ6WۄYćTH3Ny%OxwWG)\0["!K=3GSdfMab_C<8d5By와RxL똟!=zZ z[%,LbDohoVT{G X6FmԢ>i#[V;[1Ͼq&Km,z3e2 >4\`o 0iH$ZU!F#y# /,T}ч^emѐEE1Fۆ-</L&玡Q֎CN@@7de3@:9$B ݲ2?e;1%e /I`d)gQTW)H²"%uk7j<'wqd=~,A*Ef{{e49G bʑI"L~$3]1$ bͬ7'IapگOVDbe1&Z2HMOE#4*Zþ}@-Oh44M8Ss] LaqVxn| 6Co`c ~넦$\a8HLm$y6 H~זYI#&MK;#-C{4d-"O"I-St>pcS"f# RFfUh/gLm "@s2F<1z̳f`dNWޫIA34z ٻ &:3g eImmGBVt{- x;=9r~Ww(W*N<'RkAD\pS!KAYu$b=?]?[g@DmN < b60%P"k{ä|x4&C%hD8c ݶ<|!L>w9>Vbό7~5}ZSGqg\:{fQE}#X 5DԌ loy IDAT(>fbB%X29*=R;:ؠ19Ѹ9cHLO'tRqk[aaщFҞh%LC<) yG{h=`=Ƥ@ɵp|_3Eq*`Y! hn a5cSƑ~i> XP]D8oF o{N9!kO5.ߛOVm>)Z/*h\uA>\SdMS~xBh&&YuYHAzSWPmټ!ljl?A^`_8ҐSu m#If"s `$a0Tvy<a꺩t(`B<kH@1I<`Voт(NF \̛ν=MS][|rC497x v{zb>o4b }F8f1cd=[sܾ>Sfhx٤%GՕi1ul*؋'gt6oXX=a:lne@$6~g77ڷD8Oe<, mbŌέ+<ФD<&0X%!p;:V?8 4d'\. }5j}UiVER߭UǼ{cj&ih+b.ЌK/-o߱> *RH mzy5DbF%ބF#& ^Ya91˾3Ouy%Z>m,,t(8mh̟6b0m@։(]\dDJLrw6/!ǒY0b3+"] g+}bN[:cv4aWi'6O?3G߄7E5x ]Gq"0yI_b_{bˑZ}ss̢4:!@TۑGY"/T%d֋ެY``zիv+vR$>Ӻ?B@SlKhqv]td8T|DudR\#BJ6av0 $FU1;}\c3C1ɟ-\W<)`:*y`"p$ BHMGD.Y vh/ƣ 胾Ͷ+&ޛǴSc{QD2V%rr,6Pl}"м4Ec ~6 x*Dԧ>u7a޿36͇)ˎ'11L@&Z*Vx'oN0ǥ@ʪkfun$"efF+n(IHeIz31 foa1<gEuba\8x,]Gt=Ed=ḥESvhdt|DmAh_b8GosFafC{S3thr?󠮠لM\@#Ͽw N}h4< M$@H[[]N~X}#Gڍ,Y jȼO/ڇ Ԏ$_D0r`&T@F?`GCxآǓ""x߄ "R థoS M4!LYhk^Dא1EH93gP%WkYTFyfz`Ym1f9qy45 ,bц|hM2t<r.NIꪅv0TSsB LP#ܦt؉Lʦ4n_2*G%O N*Bkw=LSN9R'i!&H^җ | '+l u]u#fj G.첢HW@{ -uLHa TQ/x V)(!1!8P XaZq]BaWYhah}H4$ LN6MVfEBV]SS0mFG'7A(eZuSj$&4mJ?d>aȡ[ckPo0Z2];E4HKҖDR0 S#?"QR"rO!a3gsp+¼ ˙(+P!4oI`DC!k}>,zjU.AK@:Ź`=~ z/݆"qכTcYP!yH[|Ѝ ʿ`^؝1vɺdvStU%gƔ&I=t1F#YhuPCf' Jy__*s =l"Бt!u)KNrWzH M*5 }4m#@-2G6ۥsxj:Mme$AY2IO"#TG'< 0 \V4Lfr,J4ZY6S(4Ka bѷ &8_:xY8ؽo#LH= -F0~[$7f/c nm6g?p(8¼nMM ^0iʲfGd"O7<0E sq6ǻ+Ft"G|-ݑtiP3 ҏ_/kiRCJ$yf Lomjh+r尷h@EkT6?0ֹ k@'\im# e*dh~jS1=$rЧ$|ν8t[ )&;H0De}:l2MO鋵1Uc}ŕDy5Ai["\"Ĥun'!o< KI5_B.iHNL^( DA]JG߳hM;( =/6jmu{t[¸z xh6A%4hS54y%xL;cx)1y%·eɩ*(h3I:xKJ)m8Lѝeu#9N6&< H xFAlf6qp֒] IU$$|7YsYW~$ (> k3 !И^e]0>WL 17v䚑aB3uj-~OJx≥ }W;0f /4QHL^b*]KLYO2?wC&P]Ͱ0U1 "Dqu>&:8% 0C4;n 6k}0S"g>#0ù6c KKtF{OhNю+*x.'g* NQٱ>h81 e"8퍜Amj4gYjil@NVuڌ65J< f07fOh@Nm_1E&Ԧsvl(̬M=mO#yL5𥽡696L}&&TG1+tRvfS'FQْ#fTը`ڭw7!L h}}֣OSb^؀g,KH6 &\i3؀W3_ shʾ>%&$ ~lxA4J*NNQBi=au'&obo!DHILBaY/RY&eui@C(a7@ؘd[ &'GOe7/Y0-+:ʕ;)uI }pX":{a/p\ed" L[L4xl؋6<ʷ$)E&sFg>,G8̟01c ,7o=|ϙC&?&3uЀg% 0@%Jq p _bd͓E M$<_'{°l40#:&4W-~$o.1 HC &X_EkN:\IӆScXG#a6 onL4;sTkjSj] 4|lsb(AFKjp%ǡO`(w׽jm0eƿ^cHw2_ce98餓Je4n٘9#wkj*'WDB 76UĜBI*R86H]=mQ>1`L'sL#GfPYZXu/ egӯ1{=LDaXW>q/Еɩ~QGCmq{_G߾6Bdl$ eF,%s atu5h5F5h=|OP٤|T[̾94<#VС#8HHҵ%N$%Z҈{h<&>Y0y晅Na8iBBi _)v6Ĭ9[a>>i橙萺$/DكCUc 7 ,z_wR FVݖ)A> H16IR;f6=S2Td1!R(|269`=!>6Ւ|"ZԢ6^,D@Xx2Gu&iL]x'g)Ng}?pEk7c w`:f=c3J1{FStG[{__7jMYw}T~(E4G 0cJWL}t3gMh}j moBW_hڴ[Aߗ{e,Fex n_sTJ!m49O 1FK7~2Y}mG ɐE5˃'5 =<n(Ҝ Daq|ubf-u7Z@, Sqʷ`߉1B]1E#@ |#1$Ɯ3%$kr pvGmYĕO`9:\ Yo{A:%sLH|I_J E?B!cr,;sUT`GtI >Ӽ~42;{xR UuD{J~l *h FӉ8\O&"7My?`I6mզ.O88lFut1HT`NK^ ?D}u$#{KvMg9}9ScF7tM1OC J#&X4/ < M٫umv' FM J1B 6D5IP`(I)bT E0'AE12QZsϽ<}5|Ƹ<0 D7~q ax ct˽ܷ؄5WZ.?cR7\_xPu (4DVh_q6Q֎J`D!Z Ja(kj;8>35*7Cv-bbڲ98#F^!lڀqX~$rC`v+/ץHhIʘn.aqzѾ\ŖyյMҪ D1t]W['wc2 QbrEri j^ZeMׇ{[0r!ujhOk bn}dh]sIʭy' 8"yȬNFqHn8aAZ#`9k <fl=97b$OJkpv -`rar [1w|w|T߽@IVj?9i{.64ǪddrU%y¬~E Ab>rJ {`&g%m̠9tںl]2'N~/?U\]oλYHh5wtʂL>E߳X)3v6VYҨ <K|?05_rKkA  lµ{Z6whs-rcĉ$e~T^'ZY mbhK+pT1f &ۿ.8Uc]=M -51cxggpvB]?H$<6wJ} ^XD>5~xO*"K`J}'-Jӝe0`/K@RB3YvJ&sqҞ+O[ʯGb(Q;wpƂƱ @* UE\|a]p1k~VDahH8?EM`oUm3._!z-7M݊]ĬŸ(Ţ2.^\kv{ [F)@zWr8n4_;p  X5 քNͽD?Z1 nY?;m2n)p]=es3xq- 0,ϔ\ Rwh6_><)']r4#A~a-,O V-`Ĉr/X5: Hۮ ]`!."MY*SNXyA() Mn/ج2q^Vʾ˴ `j?x^:kOmp)[3d s!k!HhϴS$1w%Z3cmGӶgUJiHªE%^~xO@UZkCō545\q'B"X,/ , -9cӶ7 KliaH8j7\X)Ƅܛy2@:1q{ߵsUiɂTܣš +kg*I{~uWO໵d&XwfcqNW筵Y:>Y~h90G'F汘M<6PpTڏnI`핹YyMB0`Ж rBl{̳ 3גk ffJ =5FJad~* FМY(OEBe,@ 9KV}'emh5l:,5a|Un ,G<*b +'~'.풛#vMY/Y<0;K-k11 6ϡז*^{ 3=ksel&ߚ{qOY5GdNmTlsE3Rplr,3{eȣ&O \k15G~6hE`YJlF.ݲ M(ʎrЃQͱO;J~5+S,>`2քj>Yn^_Y#%k T'{U EN8se.N46oY a+b1#YNVA,MwJY]u <+3ަ#hgB p d~@,.i3Y|6h2rӍ=Jړ@k?͙ pdzɍf Κ uyW C-ͼ@Vuatc m-wS[=c v׳2dc;S[(AzUW} v,Nq?ČKcMb|}t˅{[5Ċb+sJ6,;JíY˷L2D)fp <+@b+\F~ӟp3Qd+mc@F:#EwuO(A lc,?X\'21TlA5*8_dS c3׏8ROV%c "B( H5{>6}ϵRh=ܪ,K1m$#( αM1Oì7x{ w.ʨ]glY̑f<6ۭO>7SD9)DXp3Vp":8$-{ctSV90]5G[L\ő*rۆ[{J;s`>9:]\nMԲec)`CUrLe^ xV7 sMΪ~B |-\"4$lY>7F޶ЁZb=da;Bik$Y9۾'q>{/]HY3rk P)[ sIca[JE疫MY[¿նM-ϔ4/| 7"~*55G4 {+x#G:-T*J !p MkeskL{gR W>`b-[P[ BHǾ֨рU@L^OK,!X[ffN|akq~f`E v,DJ R,̸(R6#2H%,+k ʝ:R9W7[k6F"E| pO5;G7f,(Aw 9 g a$'&}%vjrnA6u`/ACAK|jj3k̳>k Wc 0]ceQ.Xd,NM@8~fnAb,bBo8XC^~xo}A'/b>\ܑ └XmV<,ze l-ƥF ^Vcn5s,y*&8E;.7+V{ek=fuߑs`ڒbJĖ'5)hɾ' uZؙm{c g: !@1/@-@;0Į,P;%CpLwjtGGZ9!WlE{VKeh;u~"d%l_{m < {*[puκ`i疹PŌR("b52K]{ݴ&5K;f <VxPgh( :L+CJDa @TpiyaT{Un& …. f{\ d]Tmdp9'㤾{lc;uYfe&Twdoܩ"ƊzC˭Q3 ^q!/NM x ܹ|w=ERsu#8'('+X&*WfҕSf"HQ] !5lm%- *W.@o#O ll7\qHQv^qn!F>OţJk`y6 ? u0s=!-hnc<k((I,;&W^iGXk?DWE=y`uoo-S?=\mi6"E p;kEC=kM bW[)7{R:{m=U|АXtSz.@YCxmbe%OJ[IXHݳV0 3uTz2"Vӹ< կЮK- [X֎ Rh>OY|*@JIleEI*rk&1+ _ٷ=-lG0 nYEU@Vy|Ɲp ['|F/LH+ Xm_BO9 Ug@^Fؼ\{!5hX[} +%:v#vyP C-W*0vď5q}uL@he<;߇`2 m~XC%F厁XH/[;Ҋwx _l6{#4Rrsuҏϒ IDAT2JkζxxZjX-iP˅%_ m1 2+h+ G;S|&0Z<u `Zx@UE]_i(@'sjxi촍('j9;یE??XƺC'G9 88WB庑? R!KM[w-q*| 6 "?3O͟ @lRzx'8ue#`H.|ρ8O l>0%N|J n] O9|eHbí$Do(yժJ6ep00S*#F ݺ4rj'vT5ؙg:iC6\q替/<(Fŷ[)%Vlzx|0kc <\yƊǼO%-g܋!?W$W *V#mρQ8me!UFt[/bonc]k?rfW2p!dWs܋@3զ ];-ۜM y;hhkҶgS%FkP 1(mC Mf[z+Hcq41,#ck ~NƜC.k|7 9$ʛNpMu@ ם <*2éϱ]g0|(h݅w4u@\]Ř"PT47uO6pg&5r <fl'V@չ2/]3*8xL¿o&eM^+~mcE#$~$9QQf@%Z8۾4w5 m{@ >}N7z|oRކ([BKc ŝX=`d+ R{dwoϘ6TV)j<ڧ=jе 3v'\o $ڵQBG6h)* a;2|wLƬrAٗ։~\CbaD#P;B{&+rD޶Ki}Jo`X\7oo?k]I=B͇px [ BijXOf[Bl2ht`?07onƛ7F><6lx$?Es0&n ,խ*N!F V6~r/| j/j!8 Ah@d]HF]|XJխan"͚F]ZIٿUöUԞfXAH6 ix=Jl U:޷Z!,cyϽ3׿5)V7l ©QN1h#s&M!+q0!yFνmxIPx3N<+ŵ $y565멲#*KurGi* 3կYHS8R*3"ɦޫdفs+%M'C LY"&q:\sx {Ĭ I|bY<qi>:bdIˆAa}5^#gZxM <F񽀧Ms9X@J࠙Z9m$ $g{-i$|rM7^ۦV\a$l< *BO{Ճ!Wu:%&tYCGZOKJ^Vk[I\Oɣ>O90o bm߳gvXNq:aE[n-rY;w> O#+7(,J5Sɜ#ڬ 9N\RomCpz&ao(#v&{Ͻ;g?xΪN=S<\r 0{s~`(n! pmy.c|-=z=EB}f@7לv77BJ&'xR˹50V' '7F`BRʶK :~Ś>\k^.H};Js>sra1Xa~HH"'Xg cfMfAC-pygTRvh܁[ka <'>N_~O/.'#SLy抻f%Vd,Tsv9`] lL`娊ڸeNRiNJ5$&4(,?gCFs:I)zmxVwиl9⩉suI( ]xR6i[Zu~-ʨ#/-bN8_CIm4{"FC1VyrdX=FxY@}:]}KS_ _=j~qz.47 Y1NU鰆F@|Cxjl{厣 ar=:cXU6o3g"wv>`xsVGsXhZr%{ݴ-@ mӣҴY(e60 IBYSjӯjebޜg-1%EN  *,ϥww_΄W1iѠ2vɨ׮sYWqbH\~fK=TK9J*9绹"7XsK#}rgVgyxsyѮ([P_5%8 *?3kL_Oi[FF[$bˋ2+V%Ä̺{9֖1#MBi52c(]ڮ&6K:-ޟRj%s׬ڕ1Ș[7&}m=2vڵlY IJ߂'Ըlj4"$[.xE*CD_pl4;{k&hx35 7:߹z3b \qG5iTeÖ]vz-D,mW,[cfL;.2Kx { b|jr{oˮ DgΗwfu\%qjj|3BAY#2/@ `'Rg>Kl{53x68V[{i 6TY ۹*mЮsO)7B*uB %]I'h\PO$TA@E y}(t$o~za۬ɞ3`R o،xNǜol5-9~{<󕘱bh܎t{GlAVK@`޸Y o {I+ܟ۾ h" % /[V-ı[+8O90gOѣ~zV2ḿ.~tKn d !(45)s0&XlpϢ >2Cc&686x}>͛;aepH5b!P.p}VY⌒;Y4nYG̢jyNk; /eLPױظE#\iGm x/Y-G6,> K?x'#!Fjt3xHgC(qXU V?i?(5WJknp-6õ"YFJ3-I(\CxOƑ5;xP unOw_Z [۬!}0Vo'sڰ"kI\կ-lD`#_@5dz n5vmx,/":Bk,ʸl[&uy}O90gy<߿vllr~isXz`1ydqetv:C:xfy{ڛE0qLМIxnskff[ I(Zs~O9mteM^"Ak9$杬m*w$,BroU߮}bQP<|2O97xJDJ@`I5h۷hӷ ~iݣ?m|Ir=sqsЄ0}Yh߄c#_c㮰IJxƆfUsF_ !do~.}d)51v,FGD&+%t&S3c{\7] "_*z}]O! 75jަyL)|F3ڰV|uz֮ &CsZgΑ}zo; <FcrgK$b- &ÿrdA h\po`ڛ"OB#]'c}-QOW [{$нcWW7~aɍ4{mKAu6/%"Hڛ"tl@ IDATSB'U ;?;w2ܰ/%N&J5@&Ε) '$GPk;VqO6Kf+^O"Pk5'Ըˠͣ-<'bhu|O`%GXA@$tV}hx/͑p=#oxWI;-w'rlH{BH4@. %KiUXT) ˔37*,<53o7>>@;/,h>s/EKtp;*OD.^ʪ8kjK?|qg FɀaK|Z:-2ȠL4[/t%Knۏpk]oOILh,:4Fy&(seq(]Yikf΅@QQAGڬEz6#p>/y>v0Lឿܞ7?~uX@~{}}yA!W> &ā "oȢWT.?|P2X&,6.DQ9[[.О>`۶rejC-6^i6T9*,4?=gɍ{N6oZ.~Eػ7< X5"{J}deԲ{K؈*9M]sL!@{o)xJ4eVV+{ҖҀy@dFPGqEFKfMXikLGU%cnIFr^>5cv<>~O QzA˯_2^؏o G% Ibk"w ~'8%U *c 5KO's"6)$\g֕`}X)J>&q0f] ,2fj~˰ry!ϋr#ڒl`=\۔.qF;>W(H!,i1- q x$y\-R-ѶՎ.{Vz[uO90ګy\$qfyxvx\K;gLz̞[O=S@WoRiB+Xo "5k!rҊ Xrc1+@==sxbR.W:PHxf̪ Mt-8פ=XZuIdJڭ,ETI(;T%q0|"Fvٮ6y>!Y/Ro?<-֬M9.) F*s-i{+GF -~h"~piͳ{v#v G9 1ceAPk1WI^ݬ-eo_p A#+G.>WXG/Z cIݲ\S̸НY$h(Y[Jeay%^i4V- Z<\zL"&,%Sv(yMP!(yG}"c<+R_(C|&&A59-U z-V6v N -uGO[E#&oq+0"Qќ@~(,,[m < T~R:aV6H3 ˎ. M[1|qsa T/2ORȾQĚF>׭EV3\[ݾ\sy^ޕ ^j%p,1`W[/^B 룟gS](S0} OH#0ɪˎop{46+0M@:+ķsؠ߁^/h[2s\ڂD!6J>d30vs-ẕHgrd6xM3#u_u _E@a~5g <F^WۭW(H xQ*hzF@>\)8Q3^Vϖ96kՆ#|Bbs}SaGQ5py_U6F嚔4) U{̶O90[gMv5&KDHn ~f*r- |]3w?("Qtղ.^h\d'KJlk?QY+m2{f`15h3& FkmJ|:_\j8S=Y??pQx !&4'הeXjcc?I^[G; kS6:m\"P8}s`w|m"qc]IE IK#du]J$ nIG8Xrb\x>0…yD^\f!=+ǰ}R&1C_U6 tuɵSԺ mfgNv EduEƝwM_:HqX^ֺ8{>gC1)k1)00帑#uQwn,N@9Q˿`$K㽻Wnxρ|kTM'65Im ɢIN"&rKI~SCgh'*+WxyC_8ȑox1Qu 2Ce鿗֊yeqF*` H.B@5L/E W-p!اbe.o^q!dޜsZ ڵ2g<( </M~x Gߦ"e.DHôf-Z);Bnx- ˃n{qVV0f׉;E +X2ze:w pЪX3הX3LY( c9OXW~I+.-5+O{+2~=^? <,ڶ_ <Fg$p4󣃭_)CeV~BBnO>kg"{+L\hY+d\=#sgx5Is =ٚ:+jOgYRԊVkkQ;wftO'bU彀g /{C"\!hj"P|9o\W <Fvsd!"н;[$Ӝ5$M++/ẽ %6œ0caW ; 4-X<~T`>5Oƻr;܅j%TSr9<-Tذh| @&a%{ET#UM;+Ǧo[4 x99~LfZ]T 0?GcXY{k㤝ځVWl}BkӟGI۴C YPy;x&mK.@J9&_i547&7 xޙciEZYE17NjL}t,5ƻ,1W:x?{q%R;&!bKF<:UY~^ ?Ο'3빼wnD5E8̻o BxrL9ջ_reؼW׊8g <[??J} m=B">۷}e"$<'X_`?X{%i9b\/k3pYx{T:xm4DPvjv` ׉b9&5V]R.=]!wo{ܑ hxC)ÂΠ*(+@3_uK8| E_[ rG5 P]8z"dϛT&&my1*`iCV𼷒5*ޯ϶AV*-ᾷx<[ ͗52„Yȳo(Y:Fx&O90olZk΀8+KZru0 4[lk%o&!H<-gZlbj[,A72n֐5O}j)~K9Er=7 <l H+,[]n,S?:Xk5>p}GVYG=׀gLR;g 6 d|SU@.\rV?ȿ] ޽G%{'wxjC;pmɜT57\G&ˆi\q܃*C  ]?5,a<گ08zh7R3|]@[[^/M`6`,bsr<#<璻*ˋƅĜPĎ2W+ֳge 'mD<]u;w7_*!V[xVu4#5|+{b#p|Ӫ6%_KwBKvn% 46b~}ܹݻ <FLX<jkl[ t1<*s\Å, 6_ZݭVK+Z=Ru̍Xf}>3sbCN$Wx⽱~RF_??|)GC} OTqMԷxI*-T9$H/X JVᑱչuxng[`x[]ejuO&͔Fr1UN*Mȫ̌=ȓSJ[ .^ؘ x햷#G}X!MҪo$;TJfJ[JWy(mni[Ѡ4Ճ@QړF>QKt[&ْ IK{Ljo j%f~.,:>O]NsL?$:<ƒzg+V±J &)h.JUI |+k <+e<|Q]f1*C:5]l @K>< (@xm8A)񷕊)k: +1+cJܓ[w4Σ[3NMxf-d`PELx;/ =!|d1i3n PѾ &V@}6.7^Y<ՖX0,Wb<o1&" lN꧿s剅Z31ŏvN,#^M/Vr'O XLJL^šZ~aⲄ:`1wZr܂1{r/w0e엝S2g':CY;"4&B5*[c@=ph<'?ёg8Ytvx{xLH(9gjk Ʌ\Za k6+Sƺ,ZWCG n7rBS/'Wэk!VPvDD.3yڮ9 U?֑r9F|*#svxs+?8j ߽cXOBbEkn<'g{[{&b kJuFfȕU6YmoBXsy?]*hj,ij!Wao2/8G2Zs5:r3 5*x5\*ϴmJ O=]z\RSsl&%$Ar vo}iij?kĈCJ,vsgm,ܪb(<\M[r=Z!isk'|6j뼎jies#H6.a8_riheqV2m`.+,obYm,sڬ=Ji fO pR*"m>X\cY*V}DrʵZN`w }m닅!v x#SQzRٌubi|_}UpqZ0\˲!`7ڠ00m5kGqB1!Z`{9Ai hGW1Q_oц\0| ڴ)rtX_ @*yt܍cY>H*0욓h:N![Gpl=r]3^:cMzxAp j-V hrliUn~v5WZ1 48J |~~T7Moq uXc]2m')r><\I? =9uȊߑǢ^Zu_8͚"ܭ0YX/מz6OwͥuMqYOLJZ@riO; AdhlbE#BeIyGD WjM؎K.9Dx01go h):@Y9rNbNk?׵dS3!0 .OkxY}>g <֭<&e82 XNUM3ήd~o?ZƵ+)vyx\xX<{Hhpb._qgko2GIahOhd,QI,3$nąifɛϿ=fXo)L p;fPcТc#hWU"$&ƚBb?Oڎ/f/Ys)I$H%sŚߩMoնP̝I<ao 26ל <3W!~!\ߺTTNas!piLl:L|Fzqd[YKn2$Mo/ʳ7ϭtT$FSҸ1IM8ys`@ZB1M}^{kXu-YںO|;Tpi|hN67x*v "hS>M6e_` I[a]bk~c?wk'ͳVΏO )*9KBay)oZm-м]JYEn=,nտr=풵W&Qfɡť=@cMpg L;ҧU##:nm;5zP͍[5\63sYD己#x!k9y+9s`[6փr., րAnȸp О|uqѴVځMVgO!%H%MY Dy_ Ky(2,^a Yu*hKX%ظMXw{n=KV [T ?嶘C*2g4PBXG[:Y5X(K+cv[c%#SU.8@"S8IyJ5۽mf#8v6ܲx$q`,+-/*@~J7sx<zX5H %:>pڰӽ,33~6{—_|07S87p)/XA__2 X'ଁʝ`<{,96] 8ƞPe%fQtfKk.Q1(7+[[x~>K~w|s7/քq$FSϙZ'0ٗbֺs?}9X; <++{ssHzeɠL- .WA|`v(+gc*w߹=b89 zAAJ/9Scۄ@]Am\4Ye,4? ]X{@cNe\@:װV>Ũe܇'Fuնky1q;.ԨexX+?󚄧uG(s o8}Y[EԱNr7d|=QJ!yq) AGkx5@>5go5+}(1T2y<1DAI04)*yLi~BW䦡;˻~j:!YgimXpUӋ[C&ȺFpI?ݫ=k+KQ?կ>\xlmd?ŘI, QY(^cJվeCB+G<=[a!J'`Xsc[+gLH~\(֥[{.S{X&3~s0V75xaTjn% % Ul z`1quN$QyC4nؙێhgS0̪66'0^ tŵ a1.bظj9@KJ7Fi0c*Grq|Onm0$.!!Wh̏tI2X3q Z4\X+7f8Ƃ>`xW;`B^K`-pMx; ZcXyᅝ@HPֈ+KY|*ZCbckLXG]#!n hg a 9.`f"~p1jx@sY(ƃ,̛Z$p#U<' U_^ڽ (YKqs7jO-$Qߵ@1AʁzUhv4rn roEJ0>j[\b n3ߤ9Mf,@X>+=뵿30@튅y`}-{V;K}9]>tY0QQ4A&Km{O90"$(3cVwM @L@f!VKEiVYN9Vw@+E@H+ ^(Jpy6_ TX3B}DIwnC `E;G[$L 7+˰؄2F*%p"`rmƽbud^ F1Y.=-߶Y]yN6X\m?pڋpx6{E@~&LM6 X$µC4Y!Ske#PX$TWr)fGf"3gX@24sI 1I %n\ƈA ) i2{( KAH޲.l[V 7eZSmc첸}߸9eml?7<UiG3x6̣=3iQtiX8b?(|=sZBE`,aN%.m@W`BS-t$ V\P E4&~4Ė8G>mr Mp$t=wyB.򞶭kq(*%Qni}C_ii#i;ʼnBg-͵s`d@^}h 1{AJj1gCΧ./ql bZwC**Ƅ&R٣hKyHEy㖥ӂLKq]rT'S:oh.=gߍ5άİ^~s_/? 2~QAȘ;߫g??gxSP<M\%KXJ:<7\4lE&/ɠ?> D 諾./'{P5$`LY< 06We5 (ޮ6G_ cPʞoŲh,YG)\܋[K<\3Sg|"#ҋSr+XfrѴy XX\|j0Smwyx3c<|Ow63pJ5@p* D@ K O Xf6Xw)8 ?^$ B 87oS3^<"cb%"~`}۷}eLWatY(q#XzZr rPtM߽4 ڀ3m>+O;(,Rn-$~Vgy[dRU =ɵ6d}~͆hu67+~D`E9gĎ{+ˬ58b("kbb|3]~Vެ]y VKB*Lr?: 6TypX9 p˶7&&T$+ʐ<;,*GYB{ڣ*?xz7pg=D8C9 IDATWK2ќq݉ձB`OJwElF@5~PHҿkx-=O90;g)sk\|Z~ڐomB~Үρ=xU@o҆% uD,j,EF+#LP5GsQ@Ȩ-aP)tR'7m\f1Hc9otA1=FhZU~ 7wU WBT>Q9PP zT?YqC,G$׾rxcs`b<W[f49\h\^%"_؈y>QT+! d|_.scsy)!]YK[&mL Y7DJȚqM)hT0/G:QkH xd>nezQF'J8Q1*mZSyn[;Ny4+ ʳ(,Ρz}ρY<x>Iù{M nZA8P#7ޱ rr~@p" _t$8^bxU7fPTՃi޼;;oMee`9}ܱ{[Iù{ ѧ_( FW k !'AgpM#(MK nyρ;xU$@=v/|h #'(6Qe٣`+$&jyeMQ <_::p;S1sw֏9 ^ &KU^DW|\nsRiݺ!mxx[cl'Nȴ4i@{Tʿ\gTΐ64[Ie@ H8+509ݖ%e<#-=Yihܤڍf\T2c?c utV[WkBD[u w v"Mt#1r{vLj <,IJ`Ϣ17B~2= _JG2@ zk;ø <Ly~'$YMCtS_TF8s@J`)/iU"Mր>c{zqwH/q`0_P) \il4pf>Gl<ƬQkC>kxȕ&ܩgggSJt>DwN2V¯_=' )^OD+VBɅ~/uqYF5O*VKiAip|&CFW"8?~$ p?06$ HCEx9lH^Z+ӹX HbI)Oflzl6DXh2:\9+SCL<M<:2\#<06"ݺAy$B))RS)HBKuRMPĽ>%ghs'xu0D>GD@ferzQXΎtm<oK]j́5&jݻ=Z qvM{Thu9v؀ij!m}u07@`^"C!CөvO[Mp=JQrRqo/8nİǏ5֠U@tȇ{lF'\ǹOCl<Ә$4 ;ؠ^Bq4"D ʉ'21c9*Q+ S %噺e;ڮ۽T4PQY<%L<-[cZiuygt!\cY!|S@ܶY#SL4و7T !&05/pɀ8, 89MCq9gH!%!Nâb 4Q[0t+8^d PfNLM"ERN4J*|@ qBF(;U<^iqY43&\f8Syԫ>}4sܹs) |"Pwǎ? MGmgSN%yVZo&4U -FSOۜ+ABm7/V5uu=5J6yHCL<-[hꮈkmڊ=V'W`!z3' ă;4iT"ؠ_+Q DJC64#e>PƄ&rYn]R 25(|ʕtrqh3@ KvHz|eܭKC4y}mׯ粂W]9Hy*s 8yAKQ;+X6)1@߷oŋ={g #3 $|`ɒ%s =Ka+ %o!ŋ<$?}n*ۉ$+V2u>OSwzbw`'}AbH ; ^b¹cRYIku֭46xQW lq(' ,Tu"gÆ Imq<!PUۣ=91ڵkp…"ŭ_8#?)L8q7M%L\PFp/E@G|? Jp W!8CGO)G. HO8_d۶mԱݩ[;05h1PxxH6z޽نW[OyPɋ intro.html0000664000175000017500000004704014744715207013313 0ustar jfpiollejfpiolle The Recommended GHRSST Data Specification (GDS) Version 2.1r0 — The Recommended GHRSST Data Specification (GDS)

The Recommended GHRSST Data Specification (GDS) Version 2.1r0

l2p.html0000664000175000017500000046167214744715211012663 0ustar jfpiollejfpiolle 7. Level 2 Pre-processed (L2P) Product Specification — The Recommended GHRSST Data Specification (GDS)

7. Level 2 Pre-processed (L2P) Product Specification#

7.1. Overview description of the GHRSST L2P data product#

The GHRSST Level-2 Pre-processed (L2P) products are the basic building blocks from which all other GHRSST SST data products can be derived. L2P data products should ideally be made available within the GHRSST R/GTS framework to the user community in real time within 3 hours after the reception of data at the satellite.

L2P products include SST data as delivered by a data provider in their native format (swath for polar orbiting satellite), together with a number of ancillary fields that simplify interpretation and application of the SST data. The main difference between input L2 SST data file and the output GHRSST L2P data file is that additional confidence data and sensor specific error estimates for each pixel value are included and the original SST data files are reformatted into the L2P specification. No adjustments to the input L2 SST measurements are allowed but instead, sensor specific error statistics are used to provide bias error and standard deviation estimates. A user wishing to correct L2P SST data can apply these estimates to the SST values directly. Full orbit input data files may be split into ascending and descending files or smaller granules and a unique L2P output may be generated for each file. The common format of L2P products allows data users to code with the security so that as new satellite derived SST data sets are brought on-line, very minimal code changes are required to make full use of new L2P data. Time previously spent on coding different i/o routines for each satellite data set can now be spent applying the data to various applications and societal benefits instead.

The GHRSST Science Team agreed at the 6th GHRSST Science Team Meeting, Met Office, Exeter, United Kingdom, May 14th – 20th 2005, 6 mandatory fields form the core data content of a GHRSST L2P data file. These fields will be known as L2P ‘core’ (L2Pcore) fields. In addition to global attributes and geo-location and time information, GHRSST producers must provide the following L2Pcore fields within an L2P file:

  • Sea Surface Temperature data (sea_surface_temperature)

  • Time differences of SST measurements from a reference time (sst_dtime)

  • SST Sensor Specific Error Statistic (SSES) measurement bias estimate (sses_bias)

  • SSES measurement standard deviation estimate (sses_standard_deviation)

  • Flags specific to each L2P data set that help users interpret data (l2p_flags)

  • A quality level for each measurement (quality_level)

In addition there are a number of auxiliary fields (L2Paux) that must be provided before the L2P data product is admitted into the GHRSST R/GTS:

  • the difference between satellite SST measurements and a defined reference climatology of SST (dt_analysis)

  • An estimate of surface wind speed (wind_speed)

  • An estimate of sea ice fraction (sea_ice_fraction)

  • An estimate of atmospheric aerosol (as an aerosol dynamic indicator, aerosol_dyanamic_indicator)

When an L2P file contains all L2Pcore and L2Paux fields together, it will be called a full-L2P file. Only full L2P data files should be registered into the GHRSST R/G TS central catalogue. These distinctions will assist in the data management of the GHRSST GDS-2.1r0.

Missing L2Paux fields not provided by a producer may be added by a GHRSST distributor (DAC), if different from the producer, with prior arrangement. In this case data required the L2Paux files will be procured, checked for quality and interpolated or processed according to the GDS-2.1r0 specification by the DAC.

Optional experimental fields may be used by producers to provide additional information at their discretion. It may be necessary to use an additional netCDF coordinate variable when including experimental fields.

GDS-2.1r0 L2P data products are configured as shown in the table Table 7.1, which can be used to locate appropriate information in this document.

Table 7.1 Summary description of the contents of a GHRSST L2P data product#

netCDF File Contents

Description

Coordinate variables

Information to permit locating data on non-orthogonal grids, as defined in Section 6

Data record variables

Core and auxiliary variables as defined in Section 7.2

Global Attributes

A collection of required global attributes describing general characteristics of the file, as defined in section Section 5.2

7.2. L2P data record format specification#

The Table 7.2 provides an overview of the GHRSST L2P product pixel data record that should be created for each input L2 SST measurement contained within a L2P file. In the following sections, each variable within the L2P data file is described in detail.

Table 7.2 Summary description of GHRSST L2P data records#

Variable Name

Description

Units

Storage type

sea_surface_temperature

SST measurement values from input L2 satellite data set.

K (kelvin)

short

sst_dtime

The deviation in time of SST measurement from reference time

s (second)

short

sses_bias

Sensor Specific Error Statistic (SSES) bias error

K (kelvin)

byte

sses_standard_deviation

Sensor Specific Error Statistic (SSES) standard deviation uncertainty

K (kelvin)

byte

dt_analysis

The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period

K (kelvin)

byte or short

wind_speed

Closest (in time) 10 m surface wind speed from satellite or analysis

m s-1

byte

wind_speed_dtime_from_sst

Time difference of wind_speed data from input L2 SST measurement specified in hours.

h (hour)

byte

source_of_wind_speed

Source(s) of wind_speed data. Mandatory when multiple sources used.

Code

byte

sea_ice_fraction

Closest (in time) sea ice fraction from satellite or analysis

1

byte

sea_ice_fraction_dtime_from_sst

Time difference of sea_ice_fraction data from input L2 SST measurement specified in hours

h (hour)

byte

source_of_sea_ice_fraction

Source(s) of sea_ice_fraction data

code

byte

aerosol_dynamic_indicator

Atmospheric aerosol indicator

byte

adi_dtime_from_sst

Time difference between the aerosol_dynamic_indicator value and SST measurement

h (hour)

byte

source_of_adi

Source(s) of aerosol_dynamic_indicator data

code

byte

l2p_flags

Data flag values

mask of bits

short

quality_level

Overall indication of L2P data quality

enum

byte

satellite_zenith_angle

Calculated satellite zenith angle (measured at the Earth’s surface between the satellite and the zenith)

angular_degree

byte or short

solar_zenith_angle

Calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth’s surface)

degree

byte

surface_solar_irradiance

Near contemporaneous surface solar irradiance

W m-2

byte

ssi_dtime_from_sst

Time difference between the surface_solar_irradiance value and SST measurement in hours

h (hour)

byte

source_of_ssi

Source(s) of surface_solar_irradiance data

code

byte

other fields

Optional/experimental fields defined by data provider

7.2.1. sea_surface_temperature#

The variable sea_surface_temperature contains the native unmodified L2 SST of the input data file. L2 SST data are not adjusted in any manner and are identical to the input data set.

The sea_surface_temperature variable shall be included in a L2P product with the format requirements shown in table Table 7.3.

Table 7.3 CDL example description of sea_surface_temperature variable#

Storage type

Name

Description

Unit

short

sea_surface_temperature

Pixel sea surface temperature value

K (kelvin)

short sea_surface_temperature(time, nj, ni) ;
	sea_surface_temperature:_FillValue = -32768s ;
	sea_surface_temperature:long_name = "sea surface subskin temperature" ;
	sea_surface_temperature:standard_name = "sea_surface_subskin_temperature" ;
	sea_surface_temperature:units = "K" ;
	sea_surface_temperature:depth = "1 millimeter" ;
	sea_surface_temperature:source = "AVHRR_METOP_C" ;
	sea_surface_temperature:comment = "Temperature of the subskin of the ocean" ;
	sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
	sea_surface_temperature:coordinates = "lat lon" ;
	sea_surface_temperature:add_offset = 273.15 ;
	sea_surface_temperature:scale_factor = 0.01 ;

The standard_name attribute should be CF-1.7 or later compliant[1] as described in table Table 7.4:

Table 7.4 GHRSST short SST names and CF-1.7 standard names for sea_surface_temperature#

GHRSST name

CF-1.7 standard name definitions

SSTint

sea_surface_temperature

SSTskin

sea_surface_skin_temperature

SSTsubskin

sea_surface_subskin_temperature

SSTfnd

sea_surface_foundation_temperature

SSTdepth

sea_water_temperature

Note

for SSTdepth, the attribute depth should be used to indicate the depth for which the SST data are valid e.g.:

sea_surface_temperature:standard_name="sea_water_temperature";   
sea_surface_temperature:units = "K" ;   
sea_surface_temperature:depth = "1 metre" ;

7.2.2. sst_dtime#

The deviation in time of SST measurement from reference time stored in the netCDF coordinate variable time (defined as the start time of granule for L2P). Minimum resolution should be one second.

The sst_dtime variable shall be included in a L2P product with the format requirements shown in table Table 7.5.

Table 7.5 CDL example description of sst_dtime variable#

Storage type

Name

Description

Unit

short

sst_dtime

Deviation from reference time stored in the coordinate variable, time

s (seconds)

short sst_dtime(time, nj, ni) ;
	sst_dtime:_FillValue = -32768s ;
	sst_dtime:long_name = "time difference from reference time" ;
	sst_dtime:units = "s" ;
	sst_dtime:scale_factor = 1. ;
	sst_dtime:add_offset = 0. ;
	sst_dtime:coverage_content_type = "coordinate" ;
	sst_dtime:comment = "time plus sst_dtime gives seconds after 00:00:00 UTC January 1, 1981" ;
	sst_dtime:coordinates = "lat lon" ;

7.2.3. sses_bias#

Providing uncertainty estimates for each SST measurement is one of the key user requirements for GHRSST L2P SST data products. Uncertainty estimates allow users to select the accuracy level suitable for their application and to make optimum use of the SST observations (e.g. in data assimilation).

The uncertainties associated with each observation in a data stream are provided as Sensor Specific Error Statistic (SSES). The SSES are based on understanding the errors associated with the in-flight performance of an individual satellite instrument for the retrieval of SST from the measured radiances. The SSES are provided as a mean bias error and its associated standard deviation (in variable sses_standard_deviation, see Section 7.2.4).

There are a variety of methods for determining SSES as they depend on the specific characteristics of each satellite instrument. Consequently, the L2P provider can define their own scheme for producing SSES that is tailored to their specific dataset. However, the SSES scheme must conform to a set of agreed SSES common principles.

The SSES common principles are maintained on the GHRSST website, and have been approved by the GHRSST Science Team. The L2P provider must provide documentation that summarizes the theoretical basis of their SSES scheme, its implementation, any recommendations for users, and its conformance to the agreed SSES common principles.

The variable sses_bias is used to store SSES bias estimates and shall be included with the L2P format requirements shown in Table 7.6. Data producers are reminded to choose appropriate scale_factor and add_offset attributes for their data, and to strive for scale_factor as close to 0.01 as possible without “oversaturating” the values.

Table 7.6 CDL example description of sses_bias variable#

Storage type

Name

Description

Unit

byte

sses_bias

SSES bias estimate

K (kelvin)

byte sses_bias(time, nj, ni) ;
	sses_bias:_FillValue = -128b ;
	sses_bias:long_name = "SSES bias estimate" ;
	sses_bias:units = "K" ;
	sses_bias:comment = "Bias estimate derived using the techniques described at http://www.ghrsst.org/SSES-Description-of-schemes.html" ;
	sses_bias:coverage_content_type = "qualityInformation" ;
	sses_bias:coordinates = "lat lon" ;
	sses_bias:add_offset = 0. ;
	sses_bias:scale_factor = 0.01 ;

7.2.4. sses_standard_deviation#

Sensor Specific Error Statistic (SSES) standard deviation estimates are generated by the L2P data provider and are specific to a particular satellite instrument, and must conform to the SSES common principles. See Section 7.2.3 for the general description of SSES concept and associated variables.

The variable sses_standard_deviation shall be included with the format requirements shown in Table 7.7.

Data producers are reminded to choose appropriate scale_factors and add_offsets for their data, and to strive for scale_factors as close to 0.01 as possible without “oversaturating” the values.

Table 7.7 CDL example description of sses_standard_deviation variable#

Storage type

Name

Description

Unit

byte

sses_standard_deviation

SSES standard deviation.

K (kelvin)

byte sses_standard_deviation(time, nj, ni) ;
	sses_standard_deviation:_FillValue = -128b ;
	sses_standard_deviation:long_name = "SSES standard deviation" ;
	sses_standard_deviation:units = "K" ;
	sses_standard_deviation:comment = "Standard deviation estimate derived using the techniques described at http://www.ghrsst.org/SSES-Description-of-schemes.html" ;
	sses_standard_deviation:coverage_content_type = "qualityInformation" ;
	sses_standard_deviation:coordinates = "lat lon" ;
	sses_standard_deviation:add_offset = 1. ;
	sses_standard_deviation:scale_factor = 0.01 ;

7.2.5. dt_analysis#

The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period. If storage as byte does not allow the provider to offer the full precision required for this field, storage as a short is optionally permitted though byte is preferred.

The L2P variable dt_analysis is the temperature difference between an input L2 SST measurement and a reference SST L4 analysis data set. dt_analysis may be used to indicate potential areas of diurnal variability or gross outliers in the L2 input SST measurement data set by looking for large deviations from the previous analysis SST data. Note that dt_analysis is an indicator field and the temperature anomalies may be difficult to interpret in regions of high SST gradients. Furthermore, interpretation requires a good understanding of the strengths and weaknesses (e.g. space and time de-correlations) of the chosen reference L4 analysis system.

dt_analysis shall be derived using:

(7.1)#\[dt\_analysis = SST_{input} – L4_{SST}\]

Where SSTinput is the input satellite L2 measurement and L4 SST is a previous day analysis from a GHRSST L4 System selected by the data provider. The GHRSST L4 analysis chosen for a given L2P data set variable should be consistent for all L2P products as far as practically possible. If a previous analysis SSTfnd data file is not available for use in (7.1), then a mean reference SST or climatology should be used in its place as defined in Table 7.8.

Table 7.8 Reference SST data sets for use in dt_analysis computation#

Name

Description

Reference

Use code from L4 analysis

The mean SSTfnd computed for a n-1 day period. This product is computed from data provider SSTfnd data products in real time each day

https://www.ghrsst.org/ghrsst-data-services/ghrsst-catalogue/

GMPE_GLOBAL

Daily, 25 km median average SST and sea ice product created using 10 operational SST analysis products from operational centres around the world

https://ghrsst-pp.metoffice.gov.uk/ostia-website/gmpe-monitoring.html

The dt_analysis value shall be inserted into the dt_analysis field of the L2P product for the pixel in question as described Table 7.9.

Table 7.9 CDL example description of dt_analysis variable#

Storage type

Name

Description

Unit

byte or short

dt_analysis

Deviation from previous day (T-1) L4 SSTfnd analysis as defined in the Table 7.8. If no analysis is available, the reference mean SST climatology should be used

K (kelvin)

byte dt_analysis(time, nj, ni) ;
	dt_analysis:_FillValue = -128b ;
	dt_analysis:long_name = "deviation from SST analysis or reference climatology" ;
	dt_analysis:units = "K" ;
	dt_analysis:reference = "OSTIA" ;
	dt_analysis:comment = "The difference between this SST and the previous day\'s SST analysis" ;
	dt_analysis:coverage_content_type = "auxiliaryInformation" ;
	dt_analysis:coordinates = "lat lon" ;
	dt_analysis:add_offset = 0. ;
	dt_analysis:scale_factor = 0.1 ;

Note

The reference variable attribute should be used to specify the analysis or climatology used to compute dt_analysis as shown in the example above following the guidelines in Table 7.8.

7.2.6. wind_speed#

The L2P variable wind_speed contains a best estimate of the 10m surface wind speed, ideally at the time of SST data acquisition (although this is rarely possible). Wind speed measurements are required within the GDS as an indicator of the turbulent state of the air sea interface to interpret the relationship between satellite and subsurface SST data and assess the severity of any skin SST temperature deviation, thermal stratification and for use in diurnal variability adjustment schemes. At low wind speeds, especially in clear sky conditions, stronger diurnal variability is expected leading to higher surface layer temperature gradients and the potential for significant de-coupling of the skin/sub-skin SST from the SST at depth.

Ideally a near contemporaneous wind speed measurement from satellite sensors should be used but this is impossible for all sensors due to the limited number of satellite wind speed sensors available. As a surrogate for a measured wind speed value, analysis product estimates (e.g., from numerical weather prediction models) may be used as an indication of the surface wind speed. The GDS specifies the following rules:

Simultaneous microwave 10m wind speed measurements obtained from the same instrument providing the SST measurement shall be used when available to set the L2P confidence data variable wind_speed. In the absence of a simultaneous surface wind speed measurement, an analysis product estimated 10m surface wind speed shall be used to set the L2P variable wind_speed.

The difference in time expressed in hours between the time of SST measurement and the time of wind speed data should be entered into the L2P confidence data variable wind_speed_dtime_from_sst as described in Section 7.2.7. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the wind speeds have a single time value, as in the case of an analysis or model that gives the wind speeds at an instant in time, then the wind_speed_dtime_from_sst variable is not needed and instead a variable level attribute named time_offset is used. The attribute time_offset should store the difference in hours between the wind_speed and the reference time, stored in the variable time.

If a single source of data is used in the L2P variable wind_speed (recommended), the L2P variable source_of_wind_speed is not required and a source variable attribute of wind_speed is sufficient. In that case, it shall be a single source text string defined by the data provider using the text string naming best practice given in Section 4.9.

If multiple sources of data are used, source information should be indicated in the L2P variable source_of_wind_speed as defined by the data provider and as described in detail in Section 7.2.8, and the source variable attribute of wind_speed shall have the value source_of_wind_speed. In addition, the units of all sources used in the file shall be identical.

The GDS L2P variable wind_speed shall be included in L2P products with the format requirements shown in the Table 7.10.

Table 7.10 CDL example description of wind_speed variable#

Storage type

Name

Description

Unit

byte

wind_speed

Surface wind speed at 10m height. Resolution should be no less than 1 m s-1

m s-1

byte wind_speed(time, nj, ni) ;
	wind_speed:_FillValue = -128b ;
	wind_speed:long_name = "10m wind speed" ;
	wind_speed:standard_name = "wind_speed" ;
	wind_speed:units = "m s-1" ;
	wind_speed:height = "10 m" ;
	wind_speed:time_offset = 0. ;
	wind_speed:source = "WSP-ECMWF-Forecast" ;
	wind_speed:comment = "These wind speeds were created by the ECMWF and represent winds at 10 metres above the sea surface. " ;
	wind_speed:coordinates = "lat lon" ;
	wind_speed:add_offset = 0. ;
	wind_speed:scale_factor = 1. ;

A single source of wind data is shown in this example which is reported as wind_speed:source = "ECMWF_Anaylsis_V2" the code has been defined by the data provider using the ancillary data naming rules given in Section 4.9. Since all of the wind speeds have the same time, the attribute time_offset is used instead of the variable wind_speed_dtime_from_sst.

7.2.7. wind_speed_dtime_from_sst#

The variable wind_speed_dtime_from_sst reports the time difference between wind speed data and SST measurement in hours. The variable wind_speed_dtime_from_sst shall be included with the format requirements shown in Table 7.11. In the case of an analysis field, the central (mean) time of an integrated value should be used. If all values are the same, this variable is not required. Instead, use the variable level attribute named time_offset with the variable wind_speed.

Table 7.11 CDL example description of wind_speed_dtime_from_sst variable#

Storage type

Name

Description

Unit

byte

wind_speed_dtime_from_sst

This variable reports the time difference of wind speed measurement from SST measurement in hours.

h (hour)

byte wind_speed_dtime_from_sst(time, nj, ni) ;
	wind_speed_dtime_from_sst:_FillValue = -128b ;
	wind_speed_dtime_from_sst:long_name = "time difference, in hours\', of wind speed measurement from sst measurement" ;
	wind_speed_dtime_from_sst:units = "h" ;
	wind_speed_dtime_from_sst:scale_factor = 0.1 ;
	wind_speed_dtime_from_sst:add_offset = 0. ;
	wind_speed_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
	wind_speed_dtime_from_sst:comment = "the hours between the wind speed measurement and the SST observation" ;
	wind_speed_dtime_from_sst:coordinates = "lat lon" ;

7.2.8. source_of_wind_speed#

The source of data used to set the L2P ancillary data variable wind_speed shall be indicated in the L2P variable source_of_wind_speed when more than one source of wind speed data is used in the L2P product.

When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the source attribute of the wind_speed variable. If the values in that single source all have the same time, then a variable attribute time_offset set as the difference time in hours is considered sufficient and the variable wind_speed_dtime_from_sst is not required.

For multiple sources, the GDS-2.1r0 requires the following:

  • The variable in question should contain an attribute called flag_meanings and another one called flag_values. The flag_values attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the comma-separated text strings in the flag_meanings attribute.

  • These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in
    Section 4.9.

  • instead of using a _FillValue attribute and value for missing data, it is recommended to set missing pixel values to 0 and add the corresponding no_data meaning in flag_meanings attribute.

The variable source_of_wind_speed shall conform to the format requirements shown in the Table 7.12.

Table 7.12 CDL example description of source_of_wind_speed variable#

Storage type

Name

Description

Unit

byte

source_of_wind_speed

Sources of wind_speed values.

code

byte source_of_wind_speed(time, nj, ni) ;
	source_of_wind_speed:long_name = "sources of wind speed" ;
	source_of_wind_speed:flag_meanings = "no_data WSP-ESA-ASCAT-V2 WSP-NCEP-Analysis-V3 WSP-ECMWF-Forecast-V6" ;
	source_of_wind_speed:flag_values = 0b, 1b, 2b, 3b ;
	source_of_wind_speed:coverage_content_type = "auxiliaryInformation" ;
	source_of_wind_speed:comment = "This variable provides a pixel by pixel description of where the wind speeds were derived from." ;
	source_of_wind_speed:coordinates = "lat lon" ;

In this example, flag_meanings and flag_values contain strings and numeric codes provided by the data provider according to the best practices specified in Table 7.12.

7.2.9. sea_ice_fraction#

Some SST data are contaminated in part or wholly by sea ice and the L2P variable sea_ice_fraction is used to quantify the fraction of an area contaminated with sea ice, ranging from 0 to 1. Some input SST data streams provide a flag to indicate that the SST measurement is contaminated by sea ice (e.g., passive microwave radiometers such as AMSR-E).

If an input data set pixel fractional sea ice estimate exists, this should be used to in the L2P variable sea_ice_fraction as described in the table Table 7.13.

Best practice suggests that one should approach the issue in the following way. If an input data set pixel sea ice flag does not exist, and the pixel is located in or close to a region that may be ice contaminated, a reference sea ice data set should be used to determine the value of the L2P variable sea_ice_fraction.

If an input data set pixel sea ice flag exists (i.e. indicating sea ice but not the fractional amount of coverage), this should be used to set the L2P variable sea_ice_fraction to 1.

If the SST input data set includes a sea ice flag in the data stream, bit 3 of the L2P confidence data variable l2p_flags should be set for this pixel as described in Section 7.2.15.

The difference in time expressed in hours between the time of SST measurement and the time of sea ice fraction measurement should be entered into the L2P variable sea_ice_fraction_dtime_from_sst as described in in Section 7.2.10. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all ice observations have a single time value, as in the case of an analysis or model that gives the sea ice values at an instant in time, then the sea_ice_fraction_dtime_from_sst variable is not needed and instead a variable attribute named time_offset is used. The attribute time_offset should store the difference in hours between the sea_ice_fraction and the reference time, stored in the variable time.

If a single source of data is used in the L2P variable sea_ice_fraction, the L2P variable source_of_sea_ice_fraction is not required and instead the source variable attribute value of sea_ice_fraction is sufficient. It shall be a single source text string defined by the data provider using the text string naming best practice given in Section 4.9.

If multiple sources of data are used, source information should be indicated in the L2P variable source_of_sea_ice_fraction as defined by the data provider and as described in detail in Section 7.2.11, and the source variable attribute of sea_ice_fraction shall have the value source_of_sea_ice_fraction. In addition, the units of all sources used in the file shall be identical.

The variable attribute sea_ice_treatment shall specify how the sea ice information has been treated by the data provider. Valid options are: “Use unmodified (one source)”, “use unmodified (multiple ice sources)”, or “modified using onboard sensors”.

The variable sea_ice_fraction will be included with the format requirements shown in Table 7.13.

Table 7.13 CDL example description of sea_ice_fraction variable#

Storage type

Name

Description

Unit

byte

sea_ice_fraction

fractional of sea ice contamination in a given pixel. Ranges from 0 to 1.

1 (unitless)

byte sea_ice_fraction(time, nj, ni) ;
	sea_ice_fraction:_FillValue = -128b ;
	sea_ice_fraction:long_name = "sea ice fraction" ;
	sea_ice_fraction:standard_name = "sea_ice_area_fraction" ;
	sea_ice_fraction:units = "1" ;
	sea_ice_fraction:time_offset = 3. ;
	sea_ice_fraction:source = "ICE-OSISAF" ;
	sea_ice_fraction:comment = "Fractional sea ice cover from OSISAF ice product" ;
	sea_ice_fraction:coverage_content_type = "auxiliaryInformation" ;
	sea_ice_fraction:coordinates = "lat lon" ;
	sea_ice_fraction:add_offset = 0. ;
	sea_ice_fraction:scale_factor = 0.01 ;

A single source of sea ice fraction data is shown in this example which is reported as sea_ice_fraction:source = "REMSS_AMSRE_V5" following the ancillary data naming conventions specified in Section 4.9. Since all of ice values have the same time, the attribute time_offset is used instead of the variable sea_ice_fraction_dtime_from_sst.

7.2.10. sea_ice_fraction_dtime_from_sst#

The variable sea_ice_fraction_dtime_from_sst reports the time difference between sea ice fraction data from SST measurement in hours. This variable is mandatory when multiple sources of sea_ice_fraction are used.

If only one source is used, simply set a variable attribute time_offset in sea_ice_fraction variable, as the difference time in hours.

The variable sea_ice_fraction_dtime_from_sst shall be included with the format requirements shown Table 7.14.

In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the values are the same, this variable is not required. Instead, use the variable level attribute named time_offset with the variable sea_ice_fraction. The attribute time_offset should store the difference in hours between the sea ice analysis time and the reference time, stored in the variable time.

Table 7.14 CDL example description of sea_ice_fraction_dtime_from_sst variable#

Storage type

Name

Description

Unit

byte

wind_speed_dtime_from_sst

This variable reports the time difference between sea ice fraction data from SST measurement in hours.

hour

byte sea_ice_fraction_dtime_from_sst(time, nj, ni) ;
	sea_ice_fraction_dtime_from_sst:_FillValue = -128b ;
	sea_ice_fraction_dtime_from_sst:long_name = "time difference, in hours, of sea ice fraction measurement from sst measurement" ;
	sea_ice_fraction_dtime_from_sst:units = "h" ;
	sea_ice_fraction_dtime_from_sst:scale_factor = 0.1 ;
	sea_ice_fraction_dtime_from_sst:add_offset = 0. ;
	sea_ice_fraction_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
	sea_ice_fraction_dtime_from_sst:comment = "the hours between the sea ice fraction measurement and the SST observation" ;
	sea_ice_fraction_dtime_from_sst:coordinates = "lat lon" ;

This variable is mandatory when multiple sources for sea_ice_fraction are used. If only one source is used, instead simply set a variable attribute sea_ice_fraction:sea_ice_fraction_dtime_from_sst = \<difference time in hours\>.

7.2.11. source_of_sea_ice_fraction#

The source of data used to set the L2P ancillary data variable sea_ice_fraction shall be indicated in the L2P variable source_of_sea_ice_fraction when more than one source of sea ice fraction data is used in the L2P product.

When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the source attribute of the sea_ice_fraction variable.

For multiple sources, the GDS-2.1r0 requires the following:

  • The variable in question should contain an attribute called flag_meanings and another one called flag_values. The flag_values
    attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the comma-separated text
    strings in the flag_meanings attribute.

  • These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in Section 4.9.

  • instead of using a _FillValue attribute and value for missing data, it is recommended to set missing pixel values to 0 and add the corresponding no_data meaning in flag_meanings attribute.

The variable source_of_sea_ice_fraction shall conform to the format
requirements shown in Table 7.15.

Table 7.15 CDL example description of source_of_sea_ice_fraction variable#

Storage type

Name

Description

Unit

byte

source_of_sea_ice_fraction

Source(s) of sea ice values

None

byte source_of_sea_ice_fraction(time, nj, ni) ;
	source_of_sea_ice_fraction:long_name = "sources of sea ice fraction" ;
	source_of_sea_ice_fraction:flag_meanings = "no_data CE-NSIDC-AMSRE-V3 ICE-ECMWF-Forecast-V3" ;
	source_of_sea_ice_fraction:flag_values = 0b, 1b, 2b ;
	source_of_sea_ice_fraction:coverage_content_type = "auxiliaryInformation" ;
	source_of_sea_ice_fraction:comment = "This variable provides a pixel by pixel description of where the sea ice fraction were derived from." ;
	source_of_sea_ice_fraction:coordinates = "lat lon" ;

In this example, flag_meanings and flag_values contain strings and numeric codes provided by the data provider according to the best practices specified in Section 4.9.

7.2.12. aerosol_dynamic_indicator#

Mandatory (only for infrared instruments).

The L2P variable aerosol_dynamic_indicator contains an indicator of potential atmospheric aerosol contamination of infrared satellite SST data. Infrared-absorbing atmospheric aerosols are a major source of error in satellite-derived sea surface temperature retrievals. Atmospheric aerosol, such as Saharan dust outbreaks, volcanic eruptions or from coastal mega cities causes errors in the atmospheric correction of top of the atmosphere radiances when retrieving SST from infrared and visible band data sets. A systematic bias in the tropical North Atlantic Ocean and Arabian Sea due to desert dust outflows in those regions is apparent.

An aerosol indicator (e.g., derived from satellite measurements or models) value is assigned to the L2P variable aerosol_dynamic_indicator for each corresponding infrared retrieved SST measurement pixel using data chosen by the data provider to indicate aerosol contamination. The aerosol indicator data nearest in space and time to the input pixel SST value should be used. In the case of microwave SST measurements there is no requirement to include the aerosol_dynamic_indicator L2P variable as microwave SST retrievals are not affected by atmospheric aerosols. However, microwave SST data providers may include aerosol_dynamic_indicator in an L2P product.

If a single source of data is used in the L2P variable aerosol_dynamic_indicator, the L2P variable source_of_adi is not required and instead the source variable attribute value in aerosol_dynamic_indicator is sufficient. It shall be a single source text string defined by the data provider using the text string naming best practice given in Section 4.9. If all the times have the same value, then using a variable attribute time_offset with variable aerosol_dynamic_indicator is sufficient and the variable adi_dtime_from_sst is not required.

If multiple sources of ADI information are used then, the source variable attribute of aerosol_dynamic_indicator variable shall have the value source_of_adi. In addition, the units of all sources used in the file shall be identical.

The difference in time expressed in hours between the time of SST measurement and the time of aerosol indicator data should be entered into the L2P variable adi_dtime_from_sst as described in Section 7.2.13. In the case of an analysis field, this should be the central (mean) time of an integrated value.

If the variable aerosol_dynamic_indicator is provided in an L2P product, it shall be included with the format requirements shown in the Table 7.16.

Table 7.16 CDL example description of aerosol_dynamic_indicator variable#

Storage type

Name

Description

Unit

byte

aerosol_dynamic_indicator

Indicator of potential aerosol contamination of infrared satellite data

Provider defined

byte aerosol_dynamic_indicator(time, nj, ni) ;
	aerosol_dynamic_indicator:_FillValue = -128b ;
	aerosol_dynamic_indicator:long_name = "aerosol dynamic indicator" ;
	aerosol_dynamic_indicator:units = "1" ;
	aerosol_dynamic_indicator:source = "ADI-NAVO-SDI-V2" ;
	aerosol_dynamic_indicator:comment = "Estimate of the potential for aerosol contamination based on the NAVO SDI_V2 product, in counts" ;
	aerosol_dynamic_indicator:coverage_content_type = "auxiliaryInformation" ;
	aerosol_dynamic_indicator:time_offset = 3. ;
	aerosol_dynamic_indicator:coordinates = "lat lon" ;
	aerosol_dynamic_indicator:add_offset = 0. ;
	aerosol_dynamic_indicator:scale_factor = 0.1 ;

A single source of aerosol_dynamic_indicator has been used in this example indicated using the aerosol_dynamic_indicator:source and are defined by the data provider using the ancillary data naming best practice given in
Section 4.9. Since all of the values have the same time, the attribute time_offset is used instead of the variable aerosol_sst_dtime_from_sst to indicate the offset in hours from the reference variable sst_dtime.

7.2.13. adi_dtime_from_sst#

The variable adi_dtime_from_sst reports the time difference between aerosol indicator data from input L2 SST measurement in hours. The variable adi_dtime_from_sst shall be included in L2P products with the format requirements shown in the Table 7.17. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the values are the same, this variable is not required. Instead, use the variable level attribute named time_offset with the variable aerosol_dynamic_indicator.

Table 7.17 CDL example description of adi_dtime_from_sst variable#

Storage type

Name

Description

Unit

byte

adi_dtime_from_sst

Time difference of aerosol dynamic indicator data from SST measurement in hours

hour

byte sea_ice_fraction_dtime_from_sst(time, nj, ni) ;
	sea_ice_fraction_dtime_from_sst:_FillValue = -128b ;
	sea_ice_fraction_dtime_from_sst:long_name = "time difference, in hours, of sea ice fraction measurement from sst measurement" ;
	sea_ice_fraction_dtime_from_sst:units = "h" ;
	sea_ice_fraction_dtime_from_sst:scale_factor = 0.1 ;
	sea_ice_fraction_dtime_from_sst:add_offset = 0. ;
	sea_ice_fraction_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
	sea_ice_fraction_dtime_from_sst:comment = "the hours between the sea ice fraction measurement and the SST observation" ;
	sea_ice_fraction_dtime_from_sst:coordinates = "lat lon" ;

7.2.14. source_of_adi#

The source of data used to set the L2P ancillary data variable aerosol_dynamic_indicator shall be indicated in the L2P variable source_of_adi when more than one source of SSI data is used in the L2P product.

When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the sources attribute of the aerosol_dynamic_indicator variable.

For multiple sources, The variable in question should contain an attribute called flag_meanings and another one called flag_values. The flag_values attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the flag_meanings attribute. These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in Section 4.9.

instead of using a _FillValue attribute and value for missing data, it is recommended to set missing pixel values to 0 and add the corresponding no_data meaning in flag_meanings attribute.

The variable source_of_adi shall conform to the with the format requirements shown in the Table 7.18.

Table 7.18 CDL example description of source_of_adi variable#

Storage type

Name

Description

Unit

byte

source_of_adi

Sources of aerosol dynamic indicator values

None

byte source_of_adi(time, nj, ni) ;
	source_of_adi:_FillValue = -128b ;
	source_of_adi:long_name = "sources of aerosol dynamic indicator" ;
	source_of_adi:flag_meanings = "no_data AOD-NAAPS-ADI SDI-OSISAF-ADI" ;
	source_of_adi:flag_values = 0b, 1b, 2b ;
	source_of_adi:comment = "This variable provides a pixel by pixel description of where aerosol optical depth were derived from" ;
	source_of_adi:coverage_content_type = "auxiliaryInformation" ;
	source_of_adi:coordinates = "lat lon" ;

In this example, flag_meanings and flag_values contain strings and numeric codes provided by the data provider according to the best practices specified in Section 4.9.

7.2.15. l2p_flags#

Mandatory.

The GDS-2.1r0 L2P variable l2p_flags is used to

  • Specify the type of input SST data (either infrared or passive microwave instrument derived),

  • Pass through native flags from the input L2 SST data set and

  • Record any additional information considered important for the user of an L2P data set.

The L2P variable l2p_flags holds Boolean (single bit) codes detailed in its flag_meanings and flag_masks attributes, and split into two sections:

  • The first 6 bits of the L2P variable l2p_flags are generic flags that are common to all L2P data files as defined in the Table 7.19

  • Bits 6-15 are defined by the L2P data provider and are specific to each L2 input data stream

Table 7.19 List of bits composing the l2P_flags variable#

Bit

Common flags

0

Set if passive microwave data (not set is assumed to be infrared)

1

Set if over land (not set is assumed to be ocean)

2

Set if pixel is over ice

3

Set if pixel is over a lake (if known)

4

Set if pixel is over a river (if known)

5

Reserved for future data

6-15

Defined by L2 data provider

The flag_meanings attribute shall contain a space-separated list of (string with no space) descriptions for each distinct flag value. For descriptions containing multiple words, the words shall be linked by underscores.

The flag_masks attribute shall contain a comma-separated list of (numeric) mask values that isolate the bit or bits that encode each flag value, whose order matches that of the flag_meanings values.

It is recommended not to use _FillValue attribute as it is prone to misinterpretation of the bit mask.

  • Bit 0 of the L2P l2p_flags is used to record if an input pixel SST is derived from an infrared satellite sensor or a passive microwave sensor. If an input pixel is derived from a passive microwave sensor, bit 0 of the L2P l2p_flags variable should be set to 1. By not setting this flag the pixel is assumed to be from an infrared sensor.

  • Bit 1 of the L2P l2p_flags variable is used to record if an input pixel is over land or ocean surfaces. If an input pixel is classified as land covered bit 1 of the L2P l2p_flags variable should be set to equal 1. By not setting this flag the pixel is assumed to be classified as over ocean.

  • Bit 2 of the L2P l2p_flags variable is used to record if an input pixel records ice contamination. If an input pixel is classified as ice contaminated bit 2 of the L2P l2p_flags variable should be set to 1.

  • Bit 3 of the L2P l2p_flags variable is used to record if an input pixel contains any part of a lake, as defined by the GHRSST definition of lakes (mask). If an input pixel contains any part of a lake, as defined by the GHRSST definition of lakes (mask), bit 3 of the L2P l2p_flags variable should be set to 1.

  • Bit 4 of the L2P l2p_flags variable is optionally used to record if an input pixel contains any part of a river, as defined by the GHRSST definition of rivers (mask). If an input pixel contains any part of a river, as defined by the GHRSST definition of rivers (mask), bit 4 of the L2P l2p_flags variable should be set to 1.

Flags or other information provided with the input L2 SST data should be defined and assigned to the l2p_flags variable using bits 6-15 of the L2P variable l2p_flags. It is recommended to use single bits for any information, no combination of multiple bits. If that is not possible, then an additional experimental byte field should be used instead. Definitions for bits 6-15, if used, should be given using the variable comment attribute.

The L2P variable l2p_flags shall be included in GDS-2.1r0 L2P data files with the format requirements shown in Table 7.20.

Table 7.20 CDL example description of source_of_adi variable#

Storage type

Name

Description

Unit

short

l2p_flags

The variable l2p_flags is used to
(a) specify the type of input SST data (either infrared or passive microwave instrument derived),
(b) pass through native flags from the input L2 SST data set and
(c) record any additional information considered important for the user of an L2P data set

None

short l2p_flags(time, nj, ni) ;
	l2p_flags:long_name = "L2P flags" ;
	l2p_flags:flag_meanings = "microwave land ice lake" ;
	l2p_flags:flag_masks = 1s, 2s, 4s, 8s ;
	l2p_flags:comment = "These flags are important to properly use the data." ;
	l2p_flags:coverage_content_type = "qualityInformation" ;
	l2p_flags:coordinates = "lat lon" ;

7.2.16. quality_level#

Mandatory.

The L2P variable quality_level provides an indicator of the overall quality of an SST measurement in an L2P file. The GDS requires the following:

The L2P variable quality_level shall use an incremental scale from 0 to 5 to provide the user with an indication of the quality of the L2P SST data, reflecting the CEOS QA4EO (Quality Indicator) guidelines. The value 0 shall be used to indicate missing data and the value 1 shall be used to indicate invalid data (e.g. cloud, rain, too close to land - under no conditions use this data). The remaining values from 2-5 are set at the discretion of the L2P provider with the proviso that the value 2 shall be used to indicate the worst quality of usable data and the value 5 shall be used to indicate the best quality usable data. The L2P provider is required to provide a description of the quality levels provided as part of the product documentation.

The L2P variable quality_level reflects the quality of SST data from a single sensor and does not provide an indication of the relative quality between sensors.

The L2P variable quality_level shall be included with the format requirements shown in the Table 7.21.

We recommend not to use the _FillValue attribute but rather to use the value 0 to fill in missing data pixels.

Table 7.21 CDL example description of quality_level variable#

Storage type

Name

Description

Unit

byte

quality_level

Overall indicator of SST measurement quality

n/a

byte quality_level(time, nj, ni) ;
	quality_level:_FillValue = -128b ;
	quality_level:long_name = "quality level of SST pixel" ;
	quality_level:flag_meanings = "no_data bad_data worst_quality low_quality acceptable_quality best_quality" ;
	quality_level:flag_values = 0b, 1b, 2b, 3b, 4b, 5b ;
	quality_level:comment = "These are the overall quality indicators and are used for all GHRSST SSTs" ;
	quality_level:coverage_content_type = "qualityInformation" ;
	quality_level:coordinates = "lat lon" ;

7.2.17. satellite_zenith_angle#

Optional.

Sea surface temperature retrievals from satellite instruments degrade as the sensor zenith angle increases. Measurements made with high viewing angles relative to nadir appear to be considerably colder than they are in reality. The L2P variable satellite_zenith_angle contains the calculated satellite zenith angle (measured at the Earth’s surface between the satellite and the zenith) for the input L2 SST based on the satellite geometry at the time of SST data acquisition.

The GDS L2P variable satellite_zenith_angle is an optional field that may be provided by a data provider. The satellite zenith angle for each input pixel measurement should be recorded in the L2P variable satellite_zenith_angle having a range of 0° to +90°.

If the L2P variable satellite_zenith_angle is included in a L2P data product it shall conform to the format requirements shown in Table 7.22.

Table 7.22 CDL example description of satellite_zenith_angle variable#

Storage type

Name

Description

Unit

byte or short

satellite_zenith_angle

Calculated satellite zenith angle (measured at the Earth’s surface between the satellite and the local zenith) for the input L2 SST based on the satellite geometry at the time of SST data acquisition.
Ranges from 0 to 90 degrees.

angular_degree

byte satellite_zenith_angle(time, nj, ni) ;
	satellite_zenith_angle:_FillValue = -128b ;
	satellite_zenith_angle:long_name = "satellite zenith angle" ;
	satellite_zenith_angle:units = "angular_degree" ;
	satellite_zenith_angle:comment = "The satellite zenith angle at the time of the SST observations." ;
	satellite_zenith_angle:coverage_content_type = "auxiliaryInformation" ;
	satellite_zenith_angle:standard_name = "sensor_zenith_angle" ;
	satellite_zenith_angle:coordinates = "lat lon" ;
	satellite_zenith_angle:add_offset = 0. ;
	satellite_zenith_angle:scale_factor = 1. ;

7.2.18. solar_zenith_angle#

Optional.

The L2P variable solar_zenith_angle contains the calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth’s surface) for the input L2 SST based on the satellite geometry at the time of SST data acquisition. Solar zenith angle is a function of time, day number and latitude.

The GDS L2P variable solar_zenith_angle is an optional field that may be provided by a data provider. The solar zenith angle for each input pixel measurement should be recorded in the L2P variable solar_zenith_angle having a range of 0° to 180°. If the L2P variable solar_zenith_angle is included in a L2P data product it shall conform to the format requirements shown in Table 7.23.

Table 7.23 CDL example description of solar_zenith_angle variable#

Storage type

Name

Description

Unit

byte or short

solar_zenith_angle

Calculated solar zenith angle (measured at the Earth’s surface between the sun and the local zenith) for the input SST based on the solar geometry at the time of SST data acquisition.
Ranges from 0 to 180 degrees.

angular_degree

byte solar_zenith_angle(time, nj, ni) ;
	solar_zenith_angle:_FillValue = -128b ;
	solar_zenith_angle:long_name = "solar zenith angle" ;
	solar_zenith_angle:units = "angular_degree" ;
	solar_zenith_angle:comment = "The solar zenith angle at the time of the SST observations." ;
	solar_zenith_angle:coverage_content_type = "auxiliaryInformation" ;
	solar_zenith_angle:standard_name = "solar_zenith_angle" ;
	solar_zenith_angle:coordinates = "lat lon" ;
	solar_zenith_angle:add_offset = 90. ;
	solar_zenith_angle:scale_factor = 1. ;

7.2.19. surface_solar_irradiance#

Optional.

Surface Solar Irradiance (SSI) data were originally required within the GDS 1.6 to assess the magnitude and variability of significant diurnal SST variations, for use in diurnal variability correction schemes, for use in L4 SST analysis procedures and to interpret the relationship between satellite and in situ SST data. In the GDS-2.1r0, it is an optional variable. Ideally a near contemporaneous SSI measurement from satellite sensors should be used but this is impossible for all areas due to the limited number of geostationary satellite sensors available. As a surrogate for a measured SSI value, analysis estimates may be used.

Surface solar Irradiance (SSI) data may be assigned to each L2P SST measurement pixel using the variable surface_solar_irradiance.

An integrated down-welling SSI measurement (e.g., derived from satellite measurements) should be assigned to each SST pixel value using the surface_solar_irradiance L2P variable. The SSI measurement nearest in space and time before the input pixel SST value should be used. If no SSI measurement is available, an integrated SSI value derived from an analysis system nearest in space and time to the SST measurement should be used to set the value of surface_solar_irradiance.

The difference in time expressed in hours between the time of SST measurement and the time of surface solar irradiance data should be entered into the L2P confidence data variable ssi_dtime_from_sst. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the values have the same time, the attribute time_offset is used instead of the variable ssi_dtime_fraction_dtime_from_sst. The attribute time_offset should store the difference in hours between the surface_solar_irradiance and the reference time, stored in the variable time.

If a single source of data is used in the L2P variable surface_solar_irradiance, the L2P variable source_of_ssi is not required and instead the surface_solar_irradiance:source attribute value is sufficient. It shall be a single source text string defined by the data provider using the text string naming best practice given in Section 4.9.

If multiple sources of data are used, source information should be indicated in the L2P variable source_of_ssi as defined by the data provider and as described in detail in Table 7.24. Then, the surface_solar_irradiance:source attribute shall have the value source_of_ssi.

The L2P variable surface_solar_irradiance may be included by a data provider with the format requirements shown in Table 7.24.

Table 7.24 CDL example description of surface_solar_irradiance variable#

Storage type

Name

Description

Unit

byte

surface_solar_irradiance

Near contemporaneous integrated Surface Solar Irradiance (SSI) data.

\(W m^{-2}\)

byte surface_solar_irradiance(time, nj, ni) ;
	surface_solar_irradiance:long_name = "surface solar irradiance" ;
	surface_solar_irradiance:standard_name = "surface_downwelling_spherical_irradiance_in_sea_water" ;
	surface_solar_irradiance:units = "W m-2" ;
	surface_solar_irradiance:coverage_content_type = "auxiliaryInformation" ;
	surface_solar_irradiance:comment = "The surface solar irradiance as close to the SST observation times as possible" ;
	surface_solar_irradiance:scale_factor = 1.36 ;
	surface_solar_irradiance:add_offset = 127. ;
	surface_solar_irradiance:source = "SSI-MSG_SEVIRI-V1" ;
	surface_solar_irradiance:time_offset = 2. ;
	surface_solar_irradiance:coordinates = "lat lon" ;

A single source of SSI data is shown in this example which is reported as surface_solar_irradiance:source = "SSI-MSG_SEVIRI-V1" The text string has been defined by the data provider using the text string naming best practice given in Section 4.9. Since all of the SSI values have the same time, the attribute time_offset is used instead of the variable ssi_dtime_from_sst.

7.2.20. ssi_dtime_from_sst#

Optional (Mandatory only if multiple observation time for surface_solar_irradiance are provided).

The variable ssi_dtime_from_sst reports the time difference between SSI data from SST measurement in hours. The variable ssi_dtime_from_sst shall be included with the format requirements shown in Table 7.25.

In the case of an analysis field, the central (mean) time of an integrated value should be used.

If all of the values are the same, this variable is not required. Instead, use the variable level attribute named time_offset with the variable surface_solar_irradiance.

Table 7.25 CDL example description of ssi_dtime_from_sst variable#

Storage type

Name

Description

Unit

byte

ssi_dtime_from_sst

This variable reports the time difference between SSI data from SST measurement in hours

hour

byte ssi_dtime_from_sst(time, nj, ni) ;
	ssi_dtime_from_sst:_FillValue = -128b ;
	ssi_dtime_from_sst:long_name = "time difference, in hours, of surface solar irradiance measurement from sst measurement" ;
	ssi_dtime_from_sst:units = "h" ;
	ssi_dtime_from_sst:scale_factor = 0.1 ;
	ssi_dtime_from_sst:add_offset = 0. ;
	ssi_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
	ssi_dtime_from_sst:comment = "the hours between the surface solar irradiance measurement and the SST observation" ;
	ssi_dtime_from_sst:coordinates = "lat lon" ;

7.2.21. source_of_ssi#

Optional (Mandatory only if multiple sources for surface_solar_irradiance are provided).

The source of data used to set the L2P ancillary data variable surface_solar_irradiance shall be indicated in the L2P variable source_of_ssi when more than one source of SSI data is used in the L2P product. When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the source attribute of the surface_solar_irradiance variable.

For multiple sources, the variable source_of_ssi should contain an attribute called flag_meanings and another one called flag_values. The flag_values attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the flag_meanings attribute.

These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in Section 4.9.

instead of using a _FillValue attribute and value for missing data, it is recommended to set missing pixel values to 0 and add the corresponding no_data meaning in flag_meanings attribute.

The variable source_of_ssi shall conform to the format requirements shown in the Table 7.26.

Table 7.26 CDL example description of source_of_ssi variable#

Storage type

Name

Description

Unit

byte

source_of_ssi

Sources of surface solar irradiance values

code

byte source_of_ssi(time, nj, ni) ;
	source_of_ssi:long_name = "sources of surface solar irradiance" ;
	source_of_ssi:flag_meanings = "no_data SSI-MSG_SEVIRI-V1 SSI-NOAA-GOES_E-V1 SSI-NOAA-GOES_W-V1 SSI-ECMWF-V1 SSI-NCEP-V1 SSI-NAAPS-V1 spare" ;
	source_of_ssi:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 6b, 7b ;
	source_of_ssi:coverage_content_type = "auxiliaryInformation" ;
	source_of_ssi:comment = "This variable provides a pixel by pixel description of where the surface solar irradiances were derived from." ;
	source_of_ssi:coordinates = "lat lon" ;

In this example, flag_meanings and flag_values contain code data provided by the data provider according to the best practices specified in Section 4.9. An example of these codes is given in the Table 7.27.

Table 7.27 Example text string and numeric codes used to identify the sources of data in surface_solar_irradiance:sources and source_of_ssi#

Numeric Code

Text String

Sources of surface solar irradiance Description

0

no_data

No surface solar irradiance set

1

SSI-MSG_SEVIRI-V1

SSI from Meteosat Second Generation SEVIRI instrument (EUMETSAT OSI-SAF

2

SSI-NOAA-GOES_E-V1

GOES_E SSI data from NOAA

3

SSI-NOAA-GOES_W-V1

GOES_W SSI data from NOAA

4

SSI-ECMWF-V1

SSI data from European Centre for Medium Range Weather Forecasting

5

SSI-NCEP-V1

SSI data from NOAA’s National Center for Environmental Prediction

6

SSI-NAVY-NAAPS-V1

SSI data from the US Navy Atmospheric aerosol Prediction system

7

Spare to be defined as required

7.2.22. Optional experimental L2P variables included by data provider#

Flexibility of L2P product content is provided through the netCDF API, which allows fully self-describing fields and additional L2P variables may be included by L2P data providers if they are considered relevant for L2P users. The GDS-2.1r0 also permits the inclusion of R&D variables (e.g. channel radiance data sets, estimates of Chlorophyll A, fields that facilitate flagging of diurnal variability, etc.) and 32 bytes per pixel are available in total for optional/experimental variables in any combination (i.e., variables can be defined as 32 x byte, 16 x short, 3 x int + 4 x byte, etc). The use of optional/experimental variables provides a limited amount of flexibility within the GDS-2.1r0 for regional user requirements while maintaining an overall upper limit on GDS-2.1r0 L2P products for data management groups and archive scaling. In exceptional cases a waiver on the 32 byte ceiling can be requested to extend up to 64 bytes per pixel.

The GDS-2.1r0 issues the following guidance on the inclusion of optional or experimental variables within L2P data products:

  • The sum total of all experimental variables shall not increase L2P record size by more than 32 bytes per SST pixel. A waiver can be requested for higher amounts up to 64 bytes.

  • CF-1.7 or later compliance should be maintained for all optional/experimental variables. Where available, a standard_name attribute should be used.

  • It is permitted to use a provider defined coordinate variable associated with experimental fields but this shall be documented in data provider
    documentation.

  • Time difference data (dtime values) should be provided for variables when appropriate.

  • The source of data should be indicated: in the single source case as a variable attribute; as a dedicated variable when mixed data sources are present.

  • Use of experimental variables requires clear documentation by the GHRSST producer. They shall provide adequate documentation that describes each variable following the CDL examples provided in this document.

  • The variable attribute comment shall be used to provide a URL link to a full description of each data producer defined variable included in the L2P product.

  • Experimental L2P variables if present in an L2P product will be included with the minimum format requirements shown in Table 7.28

  • Additional global variables may be declared within the L2P product.

Table 7.28 CDL template for data provider defined L2P variables#

Storage type definition

Variable name definition

Description

Unit

byte

Provide a variable name in lower case using underscore separators e.g. my_variable

Provide a description of my_variable stating content purpose and units

Units of my_variable

byte my_variable(time, nj, ni) ;
	my_variable:_FillValue = -128b ;
	my_variable:long_name = "estimated diurnal variability" ;
	my_variable:standard_name = "<use_a_CF_standard_name_if_available>" ;
	my_variable:units = "K" ;
	my_variable:source = "MY-SOURCES-V1" ;
	my_variable:scale_factor = 1. ;
	my_variable:add_offset = 0. ;
	my_variable:coverage_content_type = "auxiliaryInformation" ;
	my_variable:comment = "This field is fully documented at http://www.mysite.com/my_variable-description.html" ;
	my_variable:coordinates = "lat lon" ;

7.3. CDL example L2P dataset#

The following CDL has been generated for a L2P dataset derived from the VIIRS sensor on NOAA-20 platform (https://doi.org/10.5067/GHV20-2PO28) . It includes a number of optional and experimental variables.

ADD CDL EXAMPLE


l3.html0000664000175000017500000031367514744715211012503 0ustar jfpiollejfpiolle 8. Level 3 (L3) Product Specification — The Recommended GHRSST Data Specification (GDS)

8. Level 3 (L3) Product Specification#

8.1. Overview description of the GHRSST L3 data product#

GHRSST L3 data have been introduced to provide users with gridded, synthetic, and potentially adjusted SST products, bringing added value with respect to the original L2P but still allowing traceability to the original dataset. GHRSST L3 products do not use analysis or interpolation procedure to fill gaps where no observations are available. The GHRSST L3 products include:

  • Un-collated data that represent a straightforward remapping of L2P GHRSST data granules to a space grid without combining any observations from overlapping orbits or times. Although in principle these data may or may not be adjusted to a reference sensor, in practice the un-collated L3 will normally be a remapped L2P dataset. For remapping best practices of L2P on a grid, see Section 8.4.1.

  • Collated data that grid observations from a single instrument and a single platform into space and/or time bins. These data may or may not be adjusted to a reference sensor. For collating best practices, see Section 8.4.2 and for adjustment best practices see Section 8.4.3.

  • Super-collated data that combine observations from a multiple instruments into a space-time grid. In this case, the adjustment to a common reference is necessary to avoid heterogeneities in the resulting field. For best practices concerning the creation of super collated files see Section 8.4.4

As a result, the format of a L3 file will be able to cope with the three kinds of L3 SST presented above. The L3 format will include the following parts:

  1. In case the L3 is un-adjusted, a mandatory section containing the original L2P information remapped onto the grid point: the original sea surface temperature, quality level and SSES information. An optional section including the remapping condition information may also be provided. These files are essentially gridded L2P files.

  2. In case the L3 is adjusted to a reference, the adjusted SST value must be provided, together with the local bias to the reference, the error generated by the adjustment processing, and the overall error resulting from the combination of the SSES and the adjustment processing error.

  3. In case the L3 is super-collated, the source of SST at each pixel is mandatory.

Un-adjusted files: In the case of un-collated or collated un-adjusted L3 files the L3 file is derived from L2P data by a remapping process. The remapping and collating best practices are given in Section 8.4.1. Their content is thus identical to that of the L2P, but complementary, optional information on the remapping conditions may be provided.

Adjusted files: Collated files may or may not be adjusted, but a super-collated file is necessarily adjusted. The super-collating and adjustment best practices are described in Section 8.4.2 and Section 8.4.3. The principle governing this format is to allow traceability to the original L2P, while providing the best-adjusted SST value. A first section (in blue in Table 8.1) reproduces the original L2P SST and SSES information as in the un-adjusted version. The reference used to adjust the SST must be given in the “reference” attribute of the adjusted_sea_surface_temperature variable. The adjusted SST and some error information are also mandatory. This information, in yellow in Table 8.1, is:

  • adjusted_standard_deviation_error: the total error resulting from the combination of the SSES error and the adjustment procedure error, standard_deviation_to_reference_sst.

  • bias_to_reference_sst: the local value of the estimated difference between the original SST and the reference SST

  • standard_deviation_to_reference_sst: an estimate of the error resulting from the adjustment procedure. If the procedure consists of analysing a field of differences of original SST and reference SST, the standard_deviation_to_reference_sst will be the error of this analysis.

The GHRSST Science Team determined that 5 mandatory fields will form the core data content of a GHRSST L3 data file. In addition to global attributes and geo-location information, GHRSST producers must provide the following within a L3 file:

  • Sea Surface temperature data (SST),

  • Time of SST measurement,

  • Bias and Standard Deviation error estimates for SST data,

  • Data quality.

There are a number of optional fields that may be used at the data provider’s discretion that will form the core data content of a GHRSST data file (Table 8.2).

The GHRSST L3 file contents are summarized in Table 8.1 below.

Table 8.1 Summary description of the contents within a GHRSST L3 data product#

netCDF File Contents

Description

Coordinate variables

Information to permit locating data on grids, as defined in Section 6

L2P Data record variables

Core and auxiliary variables as defined in Section 7.2

L3 Data record variables

Special Level 3 variables as defined in Table 8.2

Global Attributes

A collection of required global attributes describing general characteristics of the file, as defined in section Section 5.2

8.2. L3 data record format specification#

This table provides an overview of the GHRSST L3 product pixel data record that should be created for each input data. Within GHRSST L3 data files, there are many variables that are defined identically to their L2P counterparts. In addition, there are several variables that are unique to L3. Both types are listed below in Table 8.2. In the following sections, each variable within the L3 data file that is unique to L3 is described in detail.

Table 8.2 Summary description of GHRSST L2P data records#

Variable Name

Description

Units

Storage type

sea_surface_temperature

SST measurement values from input L2 satellite data set.

K (kelvin)

short

sst_dtime

The deviation in time of SST measurement from reference time

s (second)

short

sses_bias

Sensor Specific Error Statistic (SSES) bias error

K (kelvin)

byte

sses_standard_deviation

Sensor Specific Error Statistic (SSES) standard deviation uncertainty

K (kelvin)

byte

dt_analysis

The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period

K (kelvin)

byte or short

wind_speed

Closest (in time) 10 m surface wind speed from satellite or analysis

m s-1

byte

wind_speed_dtime_from_sst

Time difference of wind_speed data from input L2 SST measurement specified in hours.

h (hour)

byte

source_of_wind_speed

Source(s) of wind_speed data. Mandatory when multiple sources used.

Code

byte

sea_ice_fraction

Closest (in time) sea ice fraction from satellite or analysis

1

byte

sea_ice_fraction_dtime_from_sst

Time difference of sea_ice_fraction data from input L2 SST measurement specified in hours

h (hour)

byte

source_of_sea_ice_fraction

Source(s) of sea_ice_fraction data

code

byte

aerosol_dynamic_indicator

Atmospheric aerosol indicator

byte

adi_dtime_from_sst

Time difference between the aerosol_dynamic_indicator value and SST measurement

h (hour)

byte

source_of_adi

Source(s) of atmospheric aerosol indicator data

code

byte

l2p_flags

Data flag values

mask of bits

short

quality_level

Overall indication of L2P data quality

enum

byte

satellite_zenith_angle

Calculated satellite zenith angle (measured at the Earth’s surface between the satellite and the zenith)

degree

byte

solar_zenith_angle

Calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth’s surface)

degree

byte

surface_solar_irradiance

Near contemporaneous surface solar irradiance

W m-2

byte

ssi_dtime_from_sst

Time difference between the surface_solar_irradiance value and SST measurement in hours

h (hour)

byte

source_of_ssi

Source(s) of surface_solar_irradiance data

code

byte

or_latitude

Original latitude of the satellite measurement as provided in the L2P

degree_north

short or float

or_longitude

Original longitude of the satellite measurement as provided in the L2P

degree_east

short or float

or_number_of_pixels

Number of original pixels from the L2P contributing to the binned (space and/or time) average

1 (unitless)

short

sum_sst

Sum of the pixel values going into the space and/or time bin

K (kelvin)

float

sum_square_sst

Sum of the pixel value squares going into the space and/or time bin

K2 (kelvin^2)

float

adjusted_sea_surface_temperature

SST adjusted to the reference. Mandatory for adjusted type file

K (kelvin)

short

adjusted_standard_deviation_error

Total error standard deviation estimate derived from SSES and adjustment method. Mandatory for adjusted type file

K (kelvin)

byte

bias_to_reference_sst

Bias error derived from comparison with the reference. Mandatory for adjusted type file

K (kelvin)

short

standard_deviation_to_reference_sst

Error standard deviation resulting from the bias estimation method. Mandatory for adjusted type file

K (kelvin)

byte

source_of_sst

Source of SST data. Mandatory for super-collated type file

code

byte

other fields

Optional/experimental fields defined by data provider

8.2.1. or_latitude#

Optional.

This variable is the original latitude of the contributing pixel in case of remapping to the nearest pixel, or the average latitude of the contributing pixels in case of averaging.

The variable or_latitude will be included either as a floating point variable similarly to the grid latitude and longitude, or as a short variable, with the format requirements shown in Table 8.3, if the required precision is compatible.

Table 8.3 CDL example description of or_latitude variable#

Storage type

Name

Description

Unit

short or float

or_latitude

Original latitude of the satellite measurement

degree_north

short or_latitude(time, lat, lon) ;
	or_latitude:_FillValue = -32768s ;
	or_latitude:long_name = "original latitude of the SST value" ;
	or_latitude:standard_name = "latitude" ;
	or_latitude:units = "degree_north" ;
	or_latitude:coverage_content_type = "coordinate" ;
	or_latitude:authority = "CF-1.11, ACDD-1.3" ;
	or_latitude:add_offset = 0. ;
	or_latitude:scale_factor = 0.01 ;

8.2.2. or_longitude#

Optional.

This variable is the original longitude of the contributing pixel in case of remapping to the nearest pixel, or the average longitude of the contributing pixels in case of averaging.

The variable or_longitude shall be included either as a floating point variable similarly to the grid latitude and longitude, or as a short variable, with the format requirements shown in Table 8.4, if the required precision is compatible.

Table 8.4 CDL example description of or_longitude variable#

Storage type

Name

Description

Unit

short or float

or_longitude

Original longitude of the satellite measurement

degree_east

short or_longitude(time, lat, lon) ;
	or_longitude:_FillValue = -32768s ;
	or_longitude:long_name = "original longitude of the SST value" ;
	or_longitude:standard_name = "longitude" ;
	or_longitude:units = "degree_east" ;
	or_longitude:coverage_content_type = "coordinate" ;
	or_longitude:authority = "CF-1.11, ACDD-1.3" ;
	or_longitude:add_offset = 0. ;
	or_longitude:scale_factor = 0.01 ;

8.2.3. or_number_of_pixels#

Mandatory.

This variable is the number of original pixels from the L2P contributing to the binned (space and/or time) average.

The variable or_number_of_pixels shall be included with the format requirements shown in Table 8.5.

Table 8.5 CDL example description of or_number_of_pixels variable#

Storage type

Name

Description

Unit

short

or_number_of_pixels

Number of pixels from the L2P contributing to the SST value

“1” (unitless)

short or_number_of_pixels(time, lat, lon) ;
	or_number_of_pixels:_FillValue = -32768s ;
	or_number_of_pixels:long_name = "original number of pixels from the L2Ps contributing to the SST value" ;
	or_number_of_pixels:units = "1" ;
	or_number_of_pixels:standard_name = "sea_surface_foundation_temperature number_of_observations" ;
	or_number_of_pixels:coverage_content_type = "referenceInformation" ;

8.2.4. sum_sst#

Optional.

This variable is the sum of the original SST pixel values contributing to the binned (space and/or time) average.

The variable sum_sst shall be included with the format requirements shown in Table 8.6.

Table 8.6 CDL example description of sum_sst variable#

Storage type

Name

Description

Unit

short

sum_sst

Sum of the pixel values going into the space and/or time bin

K (kelvin)

float sum_sst(time, lat, lon) ;
	sum_sst:_FillValue = 1.e+20f ;
	sum_sst:long_name = "Sum of original contributing pixel sst values" ;
	sum_sst:units = "K" ;
	sum_sst:coverage_content_type = "auxiliaryInformation" ;

8.2.5. sum_square_sst#

Optional.

This variable is the sum of the squares of the original SST pixel values contributing to the binned (space and/or time) average.

The variable sum_square_sst shall be included with the format requirements shown in Table 8.7.

Table 8.7 CDL example description of sum_square_sst variable#

Storage type

Name

Description

Unit

short

sum_square_sst

Sum of the pixel value squares going into the space and/or time bin

K2

float sum_square_sst(time, lat, lon) ;
	sum_square_sst:_FillValue = 1.e+20f ;
	sum_square_sst:long_name = "Sum of contributing pixel sst value squares" ;
	sum_square_sst:units = "K2" ;
	sum_square_sst:coverage_content_type = "auxiliaryInformation" ;

8.2.6. adjusted_sea_surface_temperature#

Mandatory for adjusted type files.

This variable is the SST adjusted to the reference. See the principles of the adjustment procedure in Section 8.4.3.

The variable adjusted_sea_surface_temperature shall be included with the format requirements shown in Table 8.8.

Table 8.8 CDL example description of adjusted_sea_surface_temperature variable#

Storage type

Name

Description

Unit

short

adjusted_sea_surface_temperature

SST values after adjustment to the reference

K (kelvin)

short adjusted_sea_surface_temperature(time, lat, lon) ;
	adjusted_sea_surface_temperature:_FillValue = -32768s ;
	adjusted_sea_surface_temperature:long_name = "adjusted foundation sea surface temperature" ;
	adjusted_sea_surface_temperature:units = "K" ;
	adjusted_sea_surface_temperature:standard_name = "sea_surface_foundation_temperature" ;
	adjusted_sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
	adjusted_sea_surface_temperature:binning_method = "mean" ;
	adjusted_sea_surface_temperature:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
	adjusted_sea_surface_temperature:valid_range = -300s, 4500s ;
	adjusted_sea_surface_temperature:comment = "The recommended SST variable to use in this product. The original observations were cross-calibrated using a multi-sensor reference field\"" ;
	adjusted_sea_surface_temperature:add_offset = 273.15 ;
	adjusted_sea_surface_temperature:scale_factor = 0.01 ;

8.2.7. adjusted_standard_deviation_error#

Mandatory for adjusted type files.

This variable represents the total error associated with the adjusted_sea_surface_temperature variable. It represents the accumulated error of the SST production (the sses_standard_deviation) and the SST adjustment (standard_deviation_to_reference_sst).

The variable adjusted_standard_deviation_error shall be included with the format requirements shown in Table 8.9.

Table 8.9 CDL example description of adjusted_standard_deviation_error variable#

Storage type

Name

Description

Unit

byte

adjusted_standard_deviation_error

Total error standard deviation estimate derived from SSES and adjustment method

K (kelvin)

byte adjusted_standard_deviation_error(time, lat, lon) ;
	adjusted_standard_deviation_error:_FillValue = -128b ;
	adjusted_standard_deviation_error:long_name = "standard deviation error based on L2P SSES and adjustment method" ;
	adjusted_standard_deviation_error:units = "K" ;
	adjusted_standard_deviation_error:coverage_content_type = "qualityInformation" ;
	adjusted_standard_deviation_error:comment = "Cumulated errors of SSES and adjustment method" ;
	adjusted_standard_deviation_error:scale_factor = 0.01 ;
	adjusted_standard_deviation_error:add_offset = 1. ;

8.2.8. bias_to_reference_sst#

Mandatory for adjusted type files.

This quantity represents the local value of the adjustment to the reference.

The variable bias_to_reference_sst shall be included with the format requirements shown in Table 8.10.

Table 8.10 CDL example description of bias_to_reference_sst variable#

Storage type

Name

Description

Unit

byte

bias_to_reference_sst

Bias error derived from comparison with the reference

K (kelvin)

short bias_to_reference_sst(time, lat, lon) ;
	bias_to_reference_sst:_FillValue = -32768s ;
	bias_to_reference_sst:long_name = "bias error derived from reference" ;
	bias_to_reference_sst:units = "K" ;
	bias_to_reference_sst:comment = "Bias estimate derived from comparison between the original SST (native SSES being applied) and the reference sensor SST (original SST - reference SST)" ;
	bias_to_reference_sst:coverage_content_type = "qualityInformation" ;
	bias_to_reference_sst:add_offset = 0. ;
	bias_to_reference_sst:scale_factor = 0.01 ;

8.2.9. standard_deviation_to_reference_sst#

Mandatory for adjusted type files.

This quantity represents the local error standard deviation resulting from the bias estimation method.

The variable standard_deviation_to_reference_sst shall be included with the format requirements shown in Table 8.11.

Table 8.11 CDL example description of standard_deviation_to_reference_sst variable#

Storage type

Name

Description

Unit

short

standard_deviation_to_reference_sst

Error standard deviation resulting from the bias estimation method

K (kelvin)

byte standard_deviation_to_reference_sst(time, lat, lon) ;
	standard_deviation_to_reference_sst:_FillValue = -128b ;
	standard_deviation_to_reference_sst:long_name = "standard deviation of the reference error" ;
	standard_deviation_to_reference_sst:units = "K" ;
	standard_deviation_to_reference_sst:coverage_content_type = "qualityInformation" ;
	standard_deviation_to_reference_sst:comment = "This represents the error standard deviation estimate resulting from the bias estimation method" ;
	standard_deviation_to_reference_sst:scale_factor = 0.01 ;
	standard_deviation_to_reference_sst:add_offset = 1. ;

8.2.10. source_of_sst#

Mandatory and only applicable to super-collated (L3S) type files.

This variable represents the source(s) of SST data when merging the values from different input datasets.

When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the source attribute of the sea_surface_temperature variable.

For multiple sources, the GDS-2.1r0 requires the following:

  • The variable in question should contain an attribute called flag_meanings and another one called flag_values. The flag_values attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the comma-separated text strings in the flag_meanings attribute.

  • These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in
    Section 4.9.

In a super-collated file (L3S), the variable source_of_sst shall be included with the format requirements shown in Table 8.12.

Table 8.12 CDL example description of source_of_sst variable#

Storage type

Name

Description

Unit

byte

source_of_sst

Origin of the SST at pixel level

code

byte source_of_sst(time, lat, lon) ;
	source_of_sst:flag_values = 0b, 20b, 21b, 70b, 72b, 80b, 81b, 53b, 41b, 52b, 42b, 85b, 60b ;
	source_of_sst:flag_meanings = "no_data VIIRS_NPP-STAR-L2P-v2.80 VIIRS_N20-STAR-L2P-v2.80 AVHRR_SST_METOP_B-OSISAF-L2P-v1.0 AVHRR_SST_METOP_C-OSISAF-L2P-v1.0 SLSTRA-MAR-L2P-v1.0 SLSTRB-MAR-L2P-v1.0 ABI_G18-STAR-L3C-v2.90 SEVIRI_SST-OSISAF-L3C-v1.0 GOES16-OSISAF-L3C-v1.0 SEVIRI_IO_SST-OSISAF-L3C-v1.0 AHI_H09-STAR-L3C-v2.9 AMSR2-REMSS-L2P-v8.2" ;
	source_of_sst:long_name = "source of sea surface temperature measurement" ;
	source_of_sst:coverage_content_type = "referenceInformation" ;

8.3. Sample GHRSST L3 file (CDL header)#

A complete CDL description of a L3S dataset is given below.

netcdf \20240101000000-IFR-L3S_GHRSST-SSTfnd-ODYSSEA-GLOB_010-v02.2-fv01.0 {
dimensions:
	lat = 1600 ;
	lon = 3600 ;
	time = 1 ;
variables:
	float lat(lat) ;
		lat:_FillValue = NaNf ;
		lat:standard_name = "latitude" ;
		lat:units = "degrees_north" ;
		lat:axis = "Y" ;
		lat:long_name = "latitude" ;
		lat:authority = "CF-1.11, ACDD-1.3" ;
		lat:valid_range = -90.f, 90.f ;
		lat:comment = "geographical coordinates, WGS84 projection" ;
		lat:coverage_content_type = "coordinate" ;
	float lon(lon) ;
		lon:_FillValue = NaNf ;
		lon:standard_name = "longitude" ;
		lon:units = "degrees_east" ;
		lon:axis = "X" ;
		lon:long_name = "longitude" ;
		lon:authority = "CF-1.11, ACDD-1.3" ;
		lon:valid_range = -180.f, 180.f ;
		lon:comment = "geographical coordinates, WGS84 projection" ;
		lon:coverage_content_type = "coordinate" ;
	int64 crs ;
		crs:grid_mapping_name = "latitude_longitude" ;
		crs:longitude_of_prime_meridian = 0. ;
		crs:semi_major_axis = 6378137. ;
		crs:inverse_flattening = 298.257223563 ;
	short sea_surface_temperature(time, lat, lon) ;
		sea_surface_temperature:_FillValue = -32768s ;
		sea_surface_temperature:long_name = "sea surface foundation temperature" ;
		sea_surface_temperature:units = "K" ;
		sea_surface_temperature:standard_name = "sea_surface_foundation_temperature" ;
		sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
		sea_surface_temperature:binning_method = "mean" ;
		sea_surface_temperature:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		sea_surface_temperature:valid_range = -300s, 4500s ;
		sea_surface_temperature:add_offset = 273.15 ;
		sea_surface_temperature:scale_factor = 0.01 ;
	short or_number_of_pixels(time, lat, lon) ;
		or_number_of_pixels:_FillValue = -32768s ;
		or_number_of_pixels:long_name = "original number of pixels from the L2Ps contributing to the SST value" ;
		or_number_of_pixels:units = "1" ;
		or_number_of_pixels:standard_name = "sea_surface_foundation_temperature number_of_observations" ;
		or_number_of_pixels:coverage_content_type = "referenceInformation" ;
	byte sea_surface_temperature_stddev(time, lat, lon) ;
		sea_surface_temperature_stddev:_FillValue = -128b ;
		sea_surface_temperature_stddev:long_name = "sea_surface_subskin_temperature" ;
		sea_surface_temperature_stddev:units = "kelvin" ;
		sea_surface_temperature_stddev:standard_name = "sea_surface_subskin_temperature" ;
		sea_surface_temperature_stddev:coverage_content_type = "physicalMeasurement" ;
		sea_surface_temperature_stddev:binning_method = "std" ;
		sea_surface_temperature_stddev:cell_methods = "lat: lon: standard_deviation (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		sea_surface_temperature_stddev:add_offset = 2.54 ;
		sea_surface_temperature_stddev:scale_factor = 0.02 ;
	byte quality_level(time, lat, lon) ;
		quality_level:_FillValue = -128b ;
		quality_level:flag_meanings = "no_data bad_data worst_quality low_quality acceptable_quality best_quality" ;
		quality_level:flag_values = 0LL, 1LL, 2LL, 3LL, 4LL, 5LL ;
		quality_level:long_name = "quality level of SST pixel" ;
		quality_level:coverage_content_type = "qualityInformation" ;
		quality_level:binning_method = "mean" ;
		quality_level:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		quality_level:valid_range = 0b, 5b ;
		quality_level:standard_name = "sea_surface_foundation_temperature status_flag" ;
		quality_level:comment = "These are the overall quality indicators and are used for all GHRSST SSTs" ;
	byte sses_bias(time, lat, lon) ;
		sses_bias:_FillValue = -128b ;
		sses_bias:long_name = "SSES bias estimate" ;
		sses_bias:units = "K" ;
		sses_bias:coverage_content_type = "qualityInformation" ;
		sses_bias:binning_method = "mean" ;
		sses_bias:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		sses_bias:valid_range = -127b, 127b ;
		sses_bias:comment = "Bias estimate derived using the techniques described at http://www.ghrsst.org/SSES-Description-of-schemes.html" ;
		sses_bias:add_offset = 0. ;
		sses_bias:scale_factor = 0.02 ;
	byte sses_standard_deviation(time, lat, lon) ;
		sses_standard_deviation:_FillValue = -128b ;
		sses_standard_deviation:long_name = "SSES standard deviation" ;
		sses_standard_deviation:units = "kelvin" ;
		sses_standard_deviation:coverage_content_type = "qualityInformation" ;
		sses_standard_deviation:binning_method = "mean" ;
		sses_standard_deviation:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		sses_standard_deviation:valid_range = -127b, 127b ;
		sses_standard_deviation:comment = "Standard deviation estimate derived using the techniques described at http://www.ghrsst.org/SSES-Description-of-schemes.html" ;
		sses_standard_deviation:add_offset = 2.54 ;
		sses_standard_deviation:scale_factor = 0.02 ;
	byte satellite_zenith_angle(time, lat, lon) ;
		satellite_zenith_angle:_FillValue = -128b ;
		satellite_zenith_angle:long_name = "satellite zenith angle" ;
		satellite_zenith_angle:units = "angular_degree" ;
		satellite_zenith_angle:coverage_content_type = "referenceInformation" ;
		satellite_zenith_angle:binning_method = "mean" ;
		satellite_zenith_angle:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		satellite_zenith_angle:standard_name = "platform_zenith_angle" ;
		satellite_zenith_angle:comment = "the satellite zenith angle at the time of the SST observations" ;
		satellite_zenith_angle:add_offset = 0. ;
		satellite_zenith_angle:scale_factor = 1. ;
	short or_latitude(time, lat, lon) ;
		or_latitude:_FillValue = -32768s ;
		or_latitude:long_name = "original latitude of the SST value" ;
		or_latitude:standard_name = "latitude" ;
		or_latitude:units = "degree_north" ;
		or_latitude:coverage_content_type = "coordinate" ;
		or_latitude:authority = "CF-1.11, ACDD-1.3" ;
		or_latitude:add_offset = 0. ;
		or_latitude:scale_factor = 0.01 ;
	short or_longitude(time, lat, lon) ;
		or_longitude:_FillValue = -32768s ;
		or_longitude:long_name = "original longitude of the SST value" ;
		or_longitude:standard_name = "longitude" ;
		or_longitude:units = "degree_east" ;
		or_longitude:coverage_content_type = "coordinate" ;
		or_longitude:authority = "CF-1.11, ACDD-1.3" ;
		or_longitude:add_offset = 0. ;
		or_longitude:scale_factor = 0.01 ;
	short adjusted_sea_surface_temperature(time, lat, lon) ;
		adjusted_sea_surface_temperature:_FillValue = -32768s ;
		adjusted_sea_surface_temperature:long_name = "adjusted foundation sea surface temperature" ;
		adjusted_sea_surface_temperature:units = "K" ;
		adjusted_sea_surface_temperature:standard_name = "sea_surface_foundation_temperature" ;
		adjusted_sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
		adjusted_sea_surface_temperature:binning_method = "mean" ;
		adjusted_sea_surface_temperature:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		adjusted_sea_surface_temperature:valid_range = -300s, 4500s ;
		adjusted_sea_surface_temperature:comment = "The recommended SST variable to use in this product. The original observations were cross-calibrated using a multi-sensor reference field\"" ;
		adjusted_sea_surface_temperature:add_offset = 273.15 ;
		adjusted_sea_surface_temperature:scale_factor = 0.01 ;
	byte solar_zenith_angle(time, lat, lon) ;
		solar_zenith_angle:_FillValue = -128b ;
		solar_zenith_angle:long_name = "solar zenith angle" ;
		solar_zenith_angle:units = "angular_degree" ;
		solar_zenith_angle:standard_name = "solar_zenith_angle" ;
		solar_zenith_angle:binning_method = "mean" ;
		solar_zenith_angle:cell_methods = "lat: lon: mean (interval: 0.1 degree_N interval: 0.1 degree_E)" ;
		solar_zenith_angle:coverage_content_type = "referenceInformation" ;
		solar_zenith_angle:comment = "the solar zenith angle at the time of the SST observations" ;
		solar_zenith_angle:add_offset = 90. ;
		solar_zenith_angle:scale_factor = 1. ;
	short bias_to_reference_sst(time, lat, lon) ;
		bias_to_reference_sst:_FillValue = -32768s ;
		bias_to_reference_sst:long_name = "bias error derived from reference" ;
		bias_to_reference_sst:units = "K" ;
		bias_to_reference_sst:comment = "Bias estimate derived from comparison between the original SST (native SSES being applied) and the reference sensor SST (original SST - reference SST)" ;
		bias_to_reference_sst:coverage_content_type = "qualityInformation" ;
		bias_to_reference_sst:add_offset = 0. ;
		bias_to_reference_sst:scale_factor = 0.01 ;
	int sst_dtime(time, lat, lon) ;
		sst_dtime:_FillValue = -2147483648 ;
		sst_dtime:long_name = "time difference from reference time" ;
		sst_dtime:comment = "time plus sst_dtime gives each measurement time" ;
		sst_dtime:units = "second" ;
		sst_dtime:coverage_content_type = "coordinate" ;
	double time(time) ;
		time:_FillValue = 1.e+20 ;
		time:axis = "T" ;
		time:long_name = "reference time of sst file" ;
		time:standard_name = "time" ;
		time:authority = "CF-1.11, ACDD-1.3" ;
		time:coverage_content_type = "coordinate" ;
		time:units = "seconds since 1981-01-01" ;
		time:calendar = "proleptic_gregorian" ;
	byte source_of_sst(time, lat, lon) ;
		source_of_sst:flag_values = 0b, 20b, 21b, 70b, 72b, 80b, 81b, 53b, 41b, 52b, 42b, 85b, 60b ;
		source_of_sst:flag_meanings = "no_data VIIRS_NPP-STAR-L2P-v2.80 VIIRS_N20-STAR-L2P-v2.80 AVHRR_SST_METOP_B-OSISAF-L2P-v1.0 AVHRR_SST_METOP_C-OSISAF-L2P-v1.0 SLSTRA-MAR-L2P-v1.0 SLSTRB-MAR-L2P-v1.0 ABI_G18-STAR-L3C-v2.90 SEVIRI_SST-OSISAF-L3C-v1.0 GOES16-OSISAF-L3C-v1.0 SEVIRI_IO_SST-OSISAF-L3C-v1.0 AHI_H09-STAR-L3C-v2.9 AMSR2-REMSS-L2P-v8.2" ;
		source_of_sst:long_name = "source of sea surface temperature measurement" ;
		source_of_sst:coverage_content_type = "referenceInformation" ;
	float sum_sst(time, lat, lon) ;
		sum_sst:_FillValue = 1.e+20f ;
		sum_sst:long_name = "Sum of original contributing pixel sst values" ;
		sum_sst:units = "K" ;
		sum_sst:coverage_content_type = "auxiliaryInformation" ;
	float sum_square_sst(time, lat, lon) ;
		sum_square_sst:_FillValue = 1.e+20f ;
		sum_square_sst:long_name = "Sum of contributing pixel sst value squares" ;
		sum_square_sst:units = "K2" ;
		sum_square_sst:coverage_content_type = "auxiliaryInformation" ;
	byte adjusted_standard_deviation_error(time, lat, lon) ;
		adjusted_standard_deviation_error:_FillValue = -128b ;
		adjusted_standard_deviation_error:long_name = "standard deviation error based on L2P SSES and adjustment method" ;
		adjusted_standard_deviation_error:units = "K" ;
		adjusted_standard_deviation_error:coverage_content_type = "qualityInformation" ;
		adjusted_standard_deviation_error:comment = "Cumulated errors of SSES and adjustment method" ;
		adjusted_standard_deviation_error:scale_factor = 0.01 ;
		adjusted_standard_deviation_error:add_offset = 1. ;
	byte standard_deviation_to_reference_sst(time, lat, lon) ;
		standard_deviation_to_reference_sst:_FillValue = -128b ;
		standard_deviation_to_reference_sst:long_name = "standard deviation of the reference error" ;
		standard_deviation_to_reference_sst:units = "K" ;
		standard_deviation_to_reference_sst:coverage_content_type = "qualityInformation" ;
		standard_deviation_to_reference_sst:comment = "This represents the error standard deviation estimate resulting from the bias estimation method" ;
		standard_deviation_to_reference_sst:scale_factor = 0.01 ;
		standard_deviation_to_reference_sst:add_offset = 1. ;

// global attributes:
		:file_quality_level = 3LL ;
		:title = "ODYSSEA Global Sea Surface Temperature Gridded Level 3S Daily Multi-Sensor Observations" ;
		:id = "ODYSSEA-IFR-L3S-GLO_010-v3" ;
		:cmems_product_id = "SST_GLO_SST_L3S_NRT_OBSERVATIONS_010_010" ;
		:reference = "Product User Manual for L3S Odyssea Product over the Global Ocean, v2.1, Nov 2023, https://catalogue.marine.copernicus.eu/documents/PUM/CMEMS-SST-PUM-010-010.pdf" ;
		:summary = "This dataset provide a times series of daily multi-sensor composite fields of Sea Surface Temperature (SST) foundation at high resolution (HR) on a 0.10 x 0.10 degree grid (approximately 10 x 10 km) for the Global ocean, every 24 hours. It is produced for the Copernicus Marine Service." ;
		:metadata_link = "https://resources.marine.copernicus.eu/product-detail/SST_GLO_SST_L3S_NRT_OBSERVATIONS_010_010/INFORMATION" ;
		:date_metadata_modified = "2023-11-01T00:00:00Z" ;
		:doi = "https://doi.org/10.48670/moi-00164" ;
		:processing_level = "L3S" ;
		:publisher_institution = "Ifremer" ;
		:publisher_name = "Copernicus Marine Service" ;
		:publisher_url = "https://marine.copernicus.eu" ;
		:product_version = "1.0" ;
		:geospatial_bounds = "POLYGON ((-180.0 -80.0, 180.0 -80.0, 180.0 80.0, -180.0 80.0, -180.0 -80.0))" ;
		:geospatial_lat_max = 80. ;
		:geospatial_lat_min = -80. ;
		:geospatial_lon_max = 180. ;
		:geospatial_lon_min = -180. ;
		:spatial_resolution = "0.10 degree" ;
		:geospatial_lat_resolution = 0.1 ;
		:geospatial_lon_resolution = 0.1 ;
		:geospatial_bounds_crs = "EPSG:4326" ;
		:cdm_data_type = "grid" ;
		:time_coverage_start = "2023-12-31T12:00:00Z" ;
		:time_coverage_end = "2024-01-01T12:00:00Z" ;
		string :platform = "NPP", "NOAA-20", "Metop-B", "Metop-C", "Sentinel-3A", "Sentinel-3B", "GOES-18", "Meteosat-10", "GOES-16", "Meteosat-9", "Himawari-9", "GCOM-W" ;
		string :platform_type = "polar_orbiter", "polar_orbiter", "polar_orbiter", "polar_orbiter", "polar_orbiter", "polar_orbiter", "geostationary", "geostationary", "geostationary", "geostationary", "geostationary", "polar_orbiter" ;
		string :instrument = "VIIRS", "VIIRS", "AVHRR/3", "AVHRR/3", "SLSTR", "SLSTR", "ABI", "SEVIRI", "ABI", "SEVIRI", "AHI", "AMSR-2" ;
		string :instrument_type = "radiometer", "radiometer", "radiometer", "radiometer", "radiometer", "radiometer", "radiometer", "radiometer", "radiometer", "radiometer", "radiometer", "radiometer" ;
		string :band = "infrared", "infrared", "infrared", "infrared", "infrared", "infrared", "infrared", "infrared", "infrared", "infrared", "infrared", "microwave" ;
		:uuid = "a5f14cfc-b38f-11ee-88ca-0cc47a3fe28f" ;
		:date_created = "2024-01-15T10:20:04Z" ;
		:date_modified = "2024-01-15T10:20:04Z" ;
		:date_issued = "2024-01-15T10:20:04Z" ;
		:netcdf_version_id = "4.9.2 of Sep  1 2023 15:18:59 $" ;
		:keywords = "Oceans > Ocean Temperature > Sea Surface Temperature" ;
		:acknowledgment = "Please acknowledge the use of these data with the following statement: this dataset is produced by the Centre de Recherche et d\'Exploitation Satellitaire (CERSAT), at Ifremer, Plouzane (France): It is funded and distributed by Copernicus Marine Service" ;
		:Conventions = "CF-1.7, ACDD-1.3, ISO 8601" ;
		:standard_name_vocabulary = "Climate and Forecast (CF) Standard Name Table v79" ;
		:naming_authority = "org.ghrsst" ;
		:Metadata_Conventions = "Climate and Forecast (CF) 1.7, Attribute Convention for Data Discovery (ACDD) 1.3" ;
		:keywords_vocabulary = "NASA Global Change Master Directory (GCMD) Science Keywords" ;
		:format_version = "GHRSST GDS v2.1" ;
		:gds_version_id = "2.1" ;
		:platform_vocabulary = "CEOS mission table" ;
		:instrument_vocabulary = "CEOS instrument table" ;
		:institution = "Institut Francais de Recherche pour l\'Exploitation de la mer / Centre d\'Exploitation et de Recherche Satellitaire" ;
		:institution_abbreviation = "Ifremer / CERSAT" ;
		:project = "Group for High Resolution Sea Surface Temperature (GHRSST), Copernicus Marine Service (CMEMS)" ;
		:program = "Copernicus" ;
		:license = "These data are available free of charge under the CMEMS data policy, refer to http://marine.copernicus.eu/services-portfolio/service-commitments-and-licence/" ;
		:creator_name = "CERSAT" ;
		:creator_url = "http://cersat.ifremer.fr" ;
		:creator_email = "cersat@ifremer.fr" ;
		:creator_type = "institution" ;
		:creator_institution = "Ifremer" ;
		:contributor_name = "Jean-Francois Piolle, Emmanuelle Autret" ;
		:contributor_role = "principal investigator" ;
		:contact = "emmanuelle.autret@ifremer.fr;jfpiolle@ifremer.fr" ;
		:technical_support_contact = "cersat@ifremer.fr" ;
		:scientific_support_contact = "emmanuelle.autret@ifremer.fr;jfpiolle@ifremer.fr" ;
		:processing_software = "Telemachus 3.1.2" ;
		:source = "ODYSSEA" ;
		:source_version = "3.0.2" ;
		:history = "file originally produced by Ifremer/CERSAT with ODYSSEA system 3.0.2" ;
		:geospatial_bounds_vertical_crs = "EPSG:5831" ;
		:geospatial_lat_units = "degrees_north" ;
		:geospatial_lon_units = "degrees_east" ;
		:geospatial_vertical_min = 0. ;
		:geospatial_vertical_max = 0. ;
		:temporal_resolution = "daily" ;
		:time_coverage_resolution = "P1D" ;
		:time_coverage_duration = "P1D" ;
		:publisher_email = "cersat@ifremer.fr" ;
		:publisher_type = "institution" ;
}

8.4. Best Practices#

8.4.1. Remapping Level 2 Data to a Fixed Grid#

The remapping procedure consists in remapping the original L2P in swath projection onto a fixed grid. This remapping should preserve the traceability of the SST at pixel level and keep the best quality data.

If the original and final grid resolutions are similar, the nearest pixel remapping should be adopted. To do so, either a “source to target” or a “target to source” approach may be used. The latter, target to source, which consists in scanning the target grid points to find the nearest pixel in the source, is recommended since it avoids creating holes in the remapped field.

If the original grid resolution is finer than the output grid, Fig. 8.1 an averaging procedure can be adopted. For these cases the best practice is to average the values of all pixels which overlap the product cell entirely and which have a L2P confidence record quality_level value equal to the highest encountered within the cell, to produce a single value.

_images/regridding1.png

Fig. 8.1 To illustrate the approach when the L3 product output grid is over-sampled by the L2P input data. All pixels labeled p in the input data are possible contributors to the value for new cell A.#

The following practices are recommended by the GDS:

  1. In the case of a smaller L2P input pixel than the grid cell size, L3 data product cell values are derived from an average of the L2P pixel which completely overlap the product cell and which have a L2P quality record quality_level value equal to the highest encountered within the cell, to produce a single value.

  2. For input pixels that straddle the boundary between output grid cells, a
    weighting function may be applied to the input values according to the degree of coverage of the output grid cell and according to the SSES.

  3. Only the best quality original data within a grid cell should be averaged to produce the resulting SST value, to preserve the homogeneity of the SST quality (recommendation 1 above). In the case of averaging, the number of contributors can be recorded as well as the sum of the SST values and the sum of the square values of the SST. The SSES and ancillary data (if needed, for instance if there may be more that one SSES couple of values (bias and standard deviation) by quality level) must be averaged accordingly: the sses_bias values are averaged similarly as the SST values, the new sses_standard_deviation value is the square root of the averaged squared values of the contributing sses_standard_deviations. The averaging should account for the nature of the original l2P_flags.

  4. In the case of a larger pixel than the L3 grid cell size, 2 approaches can be adopted:

    • The value of the L2P pixel is allocated to the grid cell the closest to the pixel centre.

    • The output grid cell takes the value of the L2P pixel in which its centre lies. In this case the original latitudes and longitudes of the pixel must be recorded, to be able to detect where the original L2P pixel value has been duplicated.

If the original grid resolution is larger than the output grid (e.g., microwave instruments), as illustrated in Fig. 8.2, the following practices are recommended by the GDS:

_images/regridding2.png

Fig. 8.2 To illustrate the approach when the L3 output grid is under-sampled by the L2P data. Either Grid cell C is assigned the value of pixel p, Or grid cell A is assigned the value of pixel p and grid cell B is assigned the weighted average of p and q provided they both have quality flags with the same rating.#

8.4.2. Collating Data from the Same Sensor and Platform#

The collating procedure consists of gathering over a unique grid several orbits or slots (in the case of a geostationary satellite) of the same sensor on the same platform. This process is often known as “binning” the data. The collating procedure merges data with different times of observation.

  1. For situations in which the collation is to be done for data collected within the same day, two cases are met in practice: collation of consecutive orbits in the case of data collected from polar orbiting sensors, or the merging of consecutive slots in the case of geostationary satellites. In both cases there may be multiple candidates for a grid cell. a. To collate observations from overlapping orbits of the polar orbiting sensors, the selection procedure should prioritize data first by using the highest available quality data. If multiple observations share the same highest quality, one of two approaches should be taken: either the observation with the minimum satellite zenith angle should be selected, or the observations should be averaged. If the minimum satellite zenith angle approach is taken, the corresponding sses_bias and sses_standard_deviation should be selected as well. If the averaging approach is followed, the sses_bias and sses_standard_deviation should be averaged similarly (note that the new sses_standard_deviation value is the square root of the averaged squared values of the contributing sses_standard_deviation values). Also in the case of averaging, it is good practice to record the number of observations being averaged, the sum of the SST values, and the sum of the squared SST values. These values can be stored in the or_number_pixels, sum_sst, and sum_square_sst variables listed in Sections and 8 and 9. b. In the case of geostationary data, the selection procedure must prioritize data showing the best quality level, and if equal, data closest to the representative time (central time) of the L3 time window. In the case of geostationary satellites, remapping is not a preliminary step to the collating procedure.

  2. If averaging over multiple days, only the best quality original data within a grid cell should be averaged to produce the resulting SST value, to preserve the homogeneity of the SST quality. The number of contributors can be recorded (or_number_pixels) as well as the sum of the SST values ( sum_sst) and the sum of the square values of the SST (sum_square_sst). The SSES values should be averaged accordingly: the sses_bias values are averaged in the same manner as the SST values and the new sses_standard_deviation value is the square root of the averaged squared values of the contributing sses_standard_deviation values. The averaging should preserve the nature of the original l2P_flags.

8.4.3. SST Adjustments#

Most of individual sensors show regional biases resulting in limitations of the applied algorithms. The objective of the adjustment procedure is to provide a correction to these regional biases by comparison with a “reference sensor”, supposedly free from such biases. A variety of sources can be adopted as references in the adjustment procedure, ranging from AATSR or in situ measurement to using a median of sensors approach. The adopted reference must be recorded in the adjusted_sea_surface_temperature variable “reference” attribute.

The adjustment procedure includes the following steps:

  1. application of the SSES,

  2. determination of the bias adjustment to the reference,

  3. evaluation of the error of the adjustment procedure

Note

A skin to subskin conversion may be needed. In that case, please refer to the STVAL recommendations. The type of the SST variables must be recorded in the standard_names of the sea_surface_temperature and adjusted_sea_surface_temperature variables. The bias adjustment value at pixel and the error of the adjustment procedure must be recorded in the corresponding variables (mandatory).

8.4.4. Super-Collating Data from Multiple Sensors and Platforms#

The building of a super-collated file takes place by merging adjusted collated L3 files from various sensors over the same grid and over the same time window. There is one input candidate file (and hence one candidate observation) per sensor. There may be multiple candidates for a given grid cell originating from different sensors. To make the selection from among the candidates, a “decision tree” or selection hierarchy should be established a priori. This hierarchy depends on the objective of the super-collation procedure, and may be quite different for a moderate resolution (10km) super-collated over 24h aiming to feed a foundation SST analysis and for a high resolution (2km) hourly subskin SST super-collated aiming to feed a diurnal warming analysis, for example. Because the hierarchy must be established based on the intended use of the super-collated dataset that results, it is out of the scope of this document to define any single hierarchy. However, the adopted hierarchy must be described in the comment attribute of the adjusted_sea_surface_temperature variable. In addition, it is mandatory to provide the source of the SST (source_of_sst) at the grid cell level.

l4.html0000664000175000017500000014501614744715211012474 0ustar jfpiollejfpiolle 9. Level 4 (L4) Product Specification — The Recommended GHRSST Data Specification (GDS)

9. Level 4 (L4) Product Specification#

9.1. Overview description of the GHRSST L4 data product#

L4 products are the analyzed SST products, usually derived from GHRSST L2P products. L4 data products should ideally be made available within the GHRSST R/GTS framework to the user community within 24 hours.

L4 products include gap-free analyzed SST data together with a number of ancillary fields that simplify interpretation and application of the SST data. Data providers are responsible for providing documentation on their analysis procedure. The common format of L4 products allows data users to code with the security that as new SST data products are brought on-line, very minimal code changes are required to make full use of a new L4 product. Time previously spent on coding different I/O routines for each satellite data set can be spent working with the data to produce results.

The GHRSST Science Team determined that there will be 4 mandatory fields that form the core data content of a GHRSST L4 data file. In addition to global attributes and geo-location information, producers must include the following within a L4 file:

  • Sea Surface temperature data (SST)

  • Error estimates for SST data

  • Sea ice fraction (only and sea ice covered areas)

  • Land/sea/ice flag

In addition, there are a number of optional fields that may be used at the data provider’s discretion.

The GHRSST L4 file contents are summarized in Table 9.1 below.

Table 9.1 Summary description of the contents within a GHRSST L4 data product#

Description

Required

Coordinate variables

Information to permit locating data on grids, as defined in Section 6

Data record variables

Core and auxiliary variables as defined in Table 9.2

Global Attributes

A collection of required global attributes describing general characteristics of the file, as defined in section Section 5.2

9.2. L4 data record format specification#

L4 analysed data products are derived from an analysis procedure implemented at regular intervals (daily, six-hourly or other time periods). L4 data products include SST, error statistics, sea ice fraction, land/sea/ice mask, and other optional data for each grid-cell. A 6-byte experimental block is available for data providers to test new aspects of the file or information specific to the analysis system that will eventually transition into a GHRSST standard L4 analysis field once tested.

Table 9.2 describes the format of GDS L4 variables that should be created for each L4 grid cell. In the following sections, each variable within the L4 data file is described in detail.

Table 9.2 L4 SST product data records#

Variable Name

Description

Units

Storage type

analysed_sst

SST from analysis system

K (kelvin)

short

analysis_error

Error standard deviation estimate

K (kelvin)

short

sea_ice_fraction

Fractional Sea Ice area concentration

1 (unitless)

byte

sea_ice_fraction_error

If the error estimates on the sea ice field are available, it is recommended to provide this information as an experimental field

1 (unitless)

byte

mask

land/ice/lake mask

byte

other fields

Optional/experimental fields defined by data provider

9.2.1. analysed_sst#

The variable analysed_sst will be included with the format requirements shown in Table 9.3.

The data provider is responsible for providing GHRSST with documentation on how the analysed SST is determined. Note that the RDAC should place the _FillValue value in pixels that fall on land.

Table 9.3 CDL example description of analysed_sst variable#

Storage type

Name

Description

Unit

short

analysed_sst

SST values from analysis systems

K (kelvin)

short analysed_sst(time, lat, lon) ;
	analysed_sst:_FillValue = -32768s ;
	analysed_sst:long_name = "analysed sea surface temperature" ;
	analysed_sst:standard_name = "sea_surface_foundation_temperature" ;
	analysed_sst:units = "K" ;
	analysed_sst:coverage_content_type = "physicalMeasurement" ;
	analysed_sst:add_offset = 273.15 ;
	analysed_sst:scale_factor = 0.01 ;

9.3. analysis_error#

The variable analysis_error will be included with the format requirements shown in Table 9.4.

The data provider is responsible for providing GHRSST with documentation on how analysis_error is determined.

Table 9.4 CDL example description of analysis_error variable#

Storage type

Name

Description

Unit

short

analysis_error

Error estimate from analysis system

K (kelvin)

short analysis_error(time, lat, lon) ;
	analysis_error:_FillValue = -32768s ;
	analysis_error:long_name = "estimated error standard deviation of analysed_sst" ;
	analysis_error:units = "K" ;
	analysis_error:coverage_content_type = "qualityInformation" ;
	analysis_error:add_offset = 0. ;
	analysis_error:scale_factor = 0.01 ;

9.4. sea_ice_fraction#

The variable sea_ice_fraction will be included with the format requirements shown in Table 9.5.

Some SST data are contaminated in part or wholly by sea ice and the L4 variable sea_ice_fraction is used to quantify the fraction of an area contaminated with sea ice. If the error estimates on the sea ice field are available, it is recommended to provide this information as an experimental variable called sea_ice_fraction_error.

Table 9.5 CDL example description of sea_ice_fraction variable#

Storage type

Name

Description

Unit

byte

sea_ice_fraction

Fractional sea ice area concentration

1 (unitless)

byte sea_ice_fraction(time, lat, lon) ;
	sea_ice_fraction:_FillValue = -128b ;
	sea_ice_fraction:long_name = "sea ice area fraction" ;
	sea_ice_fraction:standard_name = "sea_ice_area_fraction" ;
	sea_ice_fraction:units = "1" ;
	sea_ice_fraction:coverage_content_type = "auxiliaryInformation" ;
	sea_ice_fraction:source = "EUMETSAT OSI-SAF" ;
	sea_ice_fraction:add_offset = 0. ;
	sea_ice_fraction:scale_factor = 0.01 ;

9.5. mask#

The variable mask will be included with the format requirements shown in Table 9.6.

Table 9.6 CDL example description of mask variable#

Storage type

Name

Description

Unit

byte

mask

land/sea/ice/lake mask

none

byte mask(time, lat, lon) ;
	mask:long_name = "land sea ice lake bit mask" ;
	mask:flag_masks = 1b, 2b, 4b, 8b ;
	mask:flag_meanings = "sea land lake ice" ;

Comments:

Comments This is a land/sea/ice mask with the following bit values:

  • Bit 0:1 = water in grid

  • Bit 1:1 = land in grid

  • Bit 2:1 = optional, lake surface in grid

  • Bit 3:1 = sea ice

  • Bit 4:1 = optional, river surface in grid

  • Bits [5-7] spare

Note that the lake and river surface bit values are optional.

The source attribute should list any data product used in creating this mask, a semi-colon separated list of identifiers <provider>_<type_of_mask>_<version_mask>.

9.6. Optional Variable sea_ice_fraction_error#

If the error estimates on the sea ice field are available, it is recommended to provide this information as an optional field called sea_ice_fraction_error. The data provider is responsible for providing GHRSST with documentation on how sea_ice_fraction_error is estimated.

Table 9.7 CDL example description of sea_ice_fraction_error variable#

Storage type

Name

Description

Unit

byte

sea_ice_fraction_error

Fractional sea ice area concentration error

1

byte sea_ice_fraction_error(time, lat, lon) ;
	sea_ice_fraction_error:_FillValue = -128b ;
	sea_ice_fraction_error:long_name = "Sea ice area fraction error estimate" ;
	sea_ice_fraction_error:units = "1" ;
	sea_ice_fraction_error:source = "EUMETSAT SAF O&SI sea ice version 1.0" ;
	sea_ice_fraction_error:scale_factor = 0.01 ;
	sea_ice_fraction_error:add_offset = 0. ;
	sea_ice_fraction_error:coverage_content_type = "auxiliaryInformation" ;
	sea_ice_fraction_error:comment = "This will be different for each system" ;

9.6.1. Optional experimental L4 variables included by data provider#

Flexibility of L4 product content is provided through the netCDF API, which allows fully self-describing fields and additional L4 variables may be included by L4 data providers if they are considered relevant for L4 users. The GDS-2.1r0 also permits the inclusion of R&D variables (e.g. estimates of sea ice fraction error, SST anomaly, etc.) and 6 bytes per pixel are available in total for optional/experimental variables in any combination (i.e., variables can be defined as 6 x byte, 3 x short, 2 x short + 2 x byte, etc). The use of optional/experimental variables provides a limited amount of flexibility within the GDS-2.1r0 for regional user requirements while maintaining an overall upper limit on GDS-2.1r0 L4 products for data management groups and archive scaling. In exceptional cases a waiver on the 6 byte ceiling can be requested to extend up to 12 bytes per pixel.

The GDS-2.1r0 issues the following guidance on the inclusion of optional or experimental variables within L4 data products:

  • The sum total of all experimental variables shall not increase L4 record size by more than 6 bytes per SST pixel. A waiver can be requested for higher amounts up to 12 bytes.

  • CF-1.7 or later compliance should be maintained for all optional/experimental variables. Where available, a standard_name attribute should be used.

  • It is permitted to use a provider defined coordinate variable associated with experimental fields but this shall be documented in data provider
    documentation.

  • Time difference data (dtime values) should be provided for variables when appropriate.

  • The source of data should be indicated: in the single source case as a variable attribute; as a dedicated variable when mixed data sources are present.

  • Use of experimental variables requires clear documentation by the GHRSST producer. They shall provide adequate documentation that describes each variable following the CDL examples provided in this document.

  • The variable attribute comment shall be used to provide a URL link to a full description of each data producer defined variable included in the L4 product.

  • Experimental L4 variables if present in an L4 product will be included with the minimum format requirements shown in Section 9.6

  • Additional global variables may be declared within the L4 product.

9.7. CDL example L4 dataset#

The following CDL has been generated for a detailed example global L4 dataset:

netcdf l4_full_example {
dimensions:
	lat = 1600 ;
	lon = 3600 ;
	time = 1 ;
variables:
	float lat(lat) ;
		lat:long_name = "latitude" ;
		lat:standard_name = "latitude" ;
		lat:axis = "Y" ;
		lat:units = "degrees_north" ;
		lat:authority = "CF-1.7" ;
		lat:valid_range = -90., 90. ;
		lat:coverage_content_type = "coordinate" ;
		lat:comment = "geographical coordinates, WGS84 projection" ;
	float lon(lon) ;
		lon:long_name = "longitude" ;
		lon:standard_name = "longitude" ;
		lon:axis = "X" ;
		lon:units = "degrees_east" ;
		lon:authority = "CF-1.7" ;
		lon:valid_range = -180., 180. ;
		lon:coverage_content_type = "coordinate" ;
		lon:comment = "geographical coordinates, WGS84 projection" ;
	short analysed_sst(time, lat, lon) ;
		analysed_sst:_FillValue = -32768s ;
		analysed_sst:long_name = "analysed sea surface temperature" ;
		analysed_sst:standard_name = "sea_surface_foundation_temperature" ;
		analysed_sst:units = "K" ;
		analysed_sst:coverage_content_type = "physicalMeasurement" ;
		analysed_sst:add_offset = 273.15 ;
		analysed_sst:scale_factor = 0.01 ;
	short analysis_error(time, lat, lon) ;
		analysis_error:_FillValue = -32768s ;
		analysis_error:long_name = "estimated error standard deviation of analysed_sst" ;
		analysis_error:units = "K" ;
		analysis_error:coverage_content_type = "qualityInformation" ;
		analysis_error:add_offset = 0. ;
		analysis_error:scale_factor = 0.01 ;
	byte mask(time, lat, lon) ;
		mask:long_name = "land sea ice lake bit mask" ;
		mask:flag_masks = 1b, 2b, 4b, 8b ;
		mask:flag_meanings = "sea land lake ice" ;
	byte sea_ice_fraction(time, lat, lon) ;
		sea_ice_fraction:_FillValue = -128b ;
		sea_ice_fraction:long_name = "sea ice area fraction" ;
		sea_ice_fraction:standard_name = "sea_ice_area_fraction" ;
		sea_ice_fraction:units = "1" ;
		sea_ice_fraction:coverage_content_type = "auxiliaryInformation" ;
		sea_ice_fraction:source = "EUMETSAT OSI-SAF" ;
		sea_ice_fraction:add_offset = 0. ;
		sea_ice_fraction:scale_factor = 0.01 ;
	double time(time) ;
		time:long_name = "reference time of field" ;
		time:standard_name = "time" ;
		time:axis = "T" ;
		time:authority = "CF-1.7" ;
		time:coverage_content_type = "coordinate" ;
		time:units = "seconds since 1981-01-01" ;
		time:calendar = "proleptic_gregorian" ;
	byte sea_ice_fraction_error(time, lat, lon) ;
		sea_ice_fraction_error:_FillValue = -128b ;
		sea_ice_fraction_error:long_name = "Sea ice area fraction error estimate" ;
		sea_ice_fraction_error:units = "1" ;
		sea_ice_fraction_error:source = "EUMETSAT SAF O&SI sea ice version 1.0" ;
		sea_ice_fraction_error:scale_factor = 0.01 ;
		sea_ice_fraction_error:add_offset = 0. ;
		sea_ice_fraction_error:coverage_content_type = "auxiliaryInformation" ;
		sea_ice_fraction_error:comment = "This will be different for each system" ;
	short sst_anomaly(time, lat, lon) ;
		sst_anomaly:_FillValue = -32768s ;
		sst_anomaly:long_name = "SST anomaly from a seasonal SST climatology based on data over 2003-2014 period" ;
		sst_anomaly:units = "K" ;
		sst_anomaly:source = "ODYSSEA L4" ;
		sst_anomaly:scale_factor = 0.001 ;
		sst_anomaly:add_offset = 0. ;
		sst_anomaly:coverage_content_type = "auxiliaryInformation" ;
		sst_anomaly:comment = "anomaly reference to the day-of-year average between 2003 and 2014" ;

// global attributes:
		:Conventions = "CF-1.7, ACDD-1.3, ISO 8601" ;
		:standard_name_vocabulary = "Climate and Forecast (CF) Standard Name Table v79" ;
		:naming_authority = "org.ghrsst" ;
		:netcdf_version_id = "4.9.2 of Sep  1 2023 15:18:59 $" ;
		:title = "ODYSSEA Global Sea Surface Temperature Gridded Level 4 Daily Multi-Sensor Observations" ;
		:id = "ODYSSEA-IFR-L4-GLOB_002-v2.1" ;
		:cmems_product_id = "SST_GLO_PHY_L4_NRT_010_043" ;
		:summary = "This dataset provide a times series of daily multi-sensor optimal interpolation of Sea Surface Temperature (SST) foundation over Global Ocean on a 0.1 degree resolution grid, every 24 hours. It is produced for the Copernicus Marine Service." ;
		:references = "Product User Manual for L4 Odyssea Product over the Global Ocean, v1.0, Jan 2023, https://catalogue.marine.copernicus.eu/documents/PUM/CMEMS-SST-PUM-010-043.pdf" ;
		:metadata_link = "https://data.marine.copernicus.eu/product/SST_GLO_PHY_L4_NRT_010_043/description" ;
		:doi = "https://doi.org/10.48670/mds-00321" ;
		:processing_level = "L4" ;
		:keywords = "Oceans > Ocean Temperature > Sea Surface Temperature" ;
		:keywords_vocabulary = "NASA Global Change Master Directory (GCMD) Science Keywords" ;
		:project = "Copernicus Marine Service" ;
		:program = "Copernicus, GHRSST" ;
		:institution = "Institut Francais de Recherche pour l\'Exploitation de la mer / Centre d\'Exploitation et de Recherche Satellitaire" ;
		:institution_abbreviation = "Ifremer / CERSAT" ;
		:license = "These data are available free of charge under the CMEMS data policy, refer to http://marine.copernicus.eu/services-portfolio/service-commitments-and-licence/" ;
		:acknowledgment = "This dataset is funded by Copernicus Marine Service" ;
		:citation = "Ifremer / CERSAT. 2022. ODYSSEA Global High-Resolution Sea Surface Temperature Gridded Level 4 Daily dataset for Copernicus Marine Service. Ver. 2.1. Ifremer, Plouzane, France. Dataset accessed [YYYY-MM-DD]." ;
		:contact = "emmanuelle.autret@ifremer.fr;jfpiolle@ifremer.fr" ;
		:technical_support_contact = "cersat@ifremer.fr" ;
		:scientific_support_contact = "emmanuelle.autret@ifremer.fr;jfpiolle@ifremer.fr" ;
		:creator_email = "cersat@ifremer.fr" ;
		:creator_type = "institution" ;
		:creator_institution = "Ifremer" ;
		:creator_name = "CERSAT" ;
		:creator_url = "http://cersat.ifremer.fr" ;
		:publisher_institution = "Copernicus Marine Service" ;
		:publisher_name = "Copernicus Marine Service" ;
		:publisher_url = "https://marine.copernicus.eu" ;
		:format_version = "GHRSST GDS v2.1" ;
		:gds_version_id = "2.1" ;
		:processing_software = "ODYSSEA OI 2.1" ;
		:source = "Odyssea L4 processor" ;
		:source_version = "3.0.2" ;
		:geospatial_bounds = "POLYGON ((-180 -80.0, 180.0 -80.0, 180.0 80.0, -180 80.0, -180 -80.0))" ;
		:geospatial_bounds_crs = "EPSG:4326" ;
		:geospatial_bounds_vertical_crs = "EPSG:5831" ;
		:geospatial_lat_max = 80. ;
		:geospatial_lat_min = -80. ;
		:geospatial_lat_resolution = 0.1 ;
		:geospatial_lat_units = "degrees_north" ;
		:geospatial_lon_max = 180. ;
		:geospatial_lon_min = -180 ;
		:geospatial_lon_resolution = 0.1 ;
		:geospatial_lon_units = "degrees_east" ;
		:geospatial_vertical_min = 0. ;
		:geospatial_vertical_max = 0. ;
		:time_coverage_start = "2024-02-28T12:00:00Z" ;
		:time_coverage_end = "2024-02-29T12:00:00Z" ;
		:time_coverage_resolution = "P1D" ;
		:spatial_resolution = " 0.1 degree" ;
		:temporal_resolution = "daily" ;
		:cdm_data_type = "grid" ;
		:source_data = "VIIRS_NPP-STAR-L2P-v2.80 VIIRS_N20-STAR-L2P-v2.80 AVHRR_SST_METOP_B-OSISAF-L2P-v1.0 AVHRR_SST_METOP_C-OSISAF-L2P-v1.0 SLSTRA-MAR-L2P-v1.0 SLSTRB-MAR-L2P-v1.0 ABI_G18-STAR-L3C-v2.90 SEVIRI_SST-OSISAF-L3C-v1.0 GOES16-OSISAF-L3C-v1.0 SEVIRI_IO_SST-OSISAF-L3C-v1.0 AHI_H09-STAR-L3C-v2.9 AMSR2-REMSS-L2P-v8.2" ;
		:platform = "NPP;NOAA-20;Metop-B;Metop-C;Sentinel-3A;Sentinel-3B;GOES-18;Meteosat-10;GOES-16;Meteosat-9;Himawari-9;GCOM-W" ;
		:platform_type = "polar_orbiter;polar_orbiter;polar_orbiter;polar_orbiter;polar_orbiter;polar_orbiter;geostationary;geostationary;geostationary;geostationary;geostationary;polar_orbiter" ;
		:platform_vocabulary = "CEOS mission table" ;
		:instrument = "VIIRS;VIIRS;AVHRR/3;AVHRR/3;SLSTR;SLSTR;ABI;SEVIRI;ABI;SEVIRI;AHI;AMSR-2" ;
		:instrument_type = "radiometer;radiometer;radiometer;radiometer;radiometer;radiometer;radiometer;radiometer;radiometer;radiometer;radiometer;radiometer" ;
		:instrument_vocabulary = "CEOS instrument table" ;
		:product_version = " 1.0" ;
		:date_created = "2024-03-05T16:23:28" ;
		:date_modified = "2024-03-05T16:23:28" ;
		:date_issued = "2024-03-05T16:23:28" ;
		:date_metadata_modified = "2023-11-01T00:00:00" ;
		:history = "Optimally interpolated SST originally produced by Ifremer/CERSAT with ODYSSEA OI processor 2.1, ODYSSEA system 3.0.2" ;
		:uuid = "2527ec2f-8d70-40d3-b56c-79757ce8574f" ;
		:file_quality_level = 3 ;
}
naming.html0000664000175000017500000015442614744715212013434 0ustar jfpiollejfpiolle 4. GDS Filenames and Supporting Conventions — The Recommended GHRSST Data Specification (GDS)

4. GDS Filenames and Supporting Conventions#

Striving to achieve a flexible naming convention that maintains consistency across processing levels and better serves user needs, the GDS uses a single form for all GHRSST data files. An overview of the format is presented below in Section 4.1 along with example filenames. Details on each of the filename convention components are provided in Section 4.2 through Section 4.8.

In addition, a best practice has been established for creating character strings used to describe GHRSST SST products and sources of ancillary data. These strings, and associated numeric codes for the SST products, are used within some GHRSST data files but are not part of the filename convention itself. The best practice is described in Section 4.9.

4.1. Overview of Filename Convention and Example Filenames#

The filenaming convention for the GDS 2.1r0 is shown below:

<Indicative Date><Indicative Time>-<RDAC>-<Processing Level>_GHRSST-<SST Type>-<Product String>-<Additional Segregator>-v<GDS Version>-fv<File Version>.<File Type>

The variable components within braces (“< >”) are summarized in Table 4.1 below and detailed in the following sections. Note that dashes (“-“) are reserved to separate elements of the file name and should not be used in any GHRSST code or the <Additional Segregator> element. Example filenames are given later in this section. While no strict limit to filename length is mandated, RDACs are encouraged to keep the length to less than 240 characters to increase readability and usability.

Table 4.1 Filenaming convention components.#

Name

Definition

Description

<Indicative Date>

YYYYMMDD

The identifying date for this data set. See Section 4.2.

<Indicative Time>

HHMMSS

The identifying time for this data set. The time used is dependent on the of the data set:
  L2P: start time of granule
  L3U: start time of granule
  L3C and L3S: centre time of the collation window
  L4 and GMPE: nominal time of analysis
All times should be given in UTC. See Section 4.3.

<RDAC>

The RDAC where the file was created

The Regional Data Assembly Centre (RDAC) code, listed in the GHRSST reference tables at https://www.ghrsst.org/resources/ghrsst-data-specification-gds-tables/. See Section 4.4.

<Processing Level>

The data processing level code (L2P, L3U, L3C, L3S, or L4)

The data processing level code, defined in Section 4.5.

<SST Type>

The type of SST data included in the file.

Conforms to the GHRSST definitions for SST, defined in Section 4.6.

<Product String>

A character string identifying the SST product set. The string is used uniquely within an RDAC but may be shared across RDACs.

The unique “name” within an RDAC of the product line. See Section 4.9 for the product string lists, one each for L2P, L3, L4, and GMPE products. See Section 4.7.

<Additional Segregator>

Optional text to distinguish between files with the same . Dashes are not allowed within this element.

This text is used since the other filename components are sometimes insufficient to uniquely identify a file. For example, in L2P or L3U (un-collated) products this is often the original file name or processing algorithm. Note, underscores should be used, not dashes. For L4 files, this element should begin with the appropriate regional code as defined in Section . This component is optional but must be used in those cases were non-unique filenames would otherwise result.

<GDS Version>

nn.n

Version number of the GDS used to process the file. For example, GDS-2.1 = “02.1”.

<File Version>

xx.x

Version number for the file, for example, “01.0”.

<File Type>

netCDF data file suffix (nc) or ISO metadata file suffix (xml)

Indicates this is a netCDF file containing data or its corresponding ISO-19115 metadata record in XML.

L2_GHRSST Filename Example 20070503132300-NAVO-L2P_GHRSST-SSTblend-AVHRR17_L-SST_s0123_e0135-v02.1-fv01.0.nc

The above file contains GHRSST L2P blended SST data for 03 May 2007, from AVHRR LAC data collected from the NOAA-17 platform. The granule begins at 13:23:00 hours. It is version 1.0 of the file and was produced by the NAVO RDAC in accordance with the GDS 2.1r0. The <Additional Segregator> text is “SST_s0123_e0135”.

L3_GHRSST Filename Example 20070503110153-REMSS-L3C_GHRSST-SSTsubskin-TMI-tmi_20070503rt-v02.1-fv01.0.nc

The above file was produced by the REMSS RDAC and contains collated L3 sub-skin SST data from the TMI instrument for 03 May 2007. The collated file has a centre time of at 11:01:53 hours. It is version 1.0 of the file and was produced according to GDS 2.1r0 specifications. Its <Additional Segregator> text is “tmi_20070503rt”.

L4_GHRSST Filename Example 20070503120000-UKMO-L4_GHRSST-SSTfnd-OSTIA-GLOB-v02.1-fv01.0.nc

The above file contains L4 foundation SST data produced at the UKMO RDAC using the OSTIA system. It is global coverage, contains data for 03 May 2007, was produced to GDS 2.1r0 specifications and is version 1.0 of the file. The nominal time of the OSTIA analysis is 12:00:00 hours.

4.2. <Indicative Date>#

The identifying date for this data set, using the format YYYYMMDD, where YYYY is the four-digit year, MM is the two-digit month from 01 to 12, and DD is the two-digit day of month from 01 to 31. The date used should best represent the observation date for the dataset.

4.3. <Indicative Time>#

The identifying time for this data set in UTC, using the format HHMMSS, where HH is the two-digit hour from 00 to 23, MM is the two-digit minute from 00 to 59, and SS is the two-digit second from 00 to 59. The time used is dependent on the <Processing Level> of the data set:

  • L2P: start time of granule

  • L3U: start time of granule

  • L3C and L3S: centre time of the collation window

  • L4 and GMPE: nominal time of analysis

All times should be given in UTC and should be chosen to best represent the observation time for this dataset. Note: RDACs should ensure the applications they use to determine UTC proprerly account for leap seconds.

4.4. <RDAC>#

Codes used for GHRSST Regional Data Assembly Centres (RDACs) are available on the GHRSST website (https://www.ghrsst.org/resources/ghrsst-data-specification-gds-tables/). New codes are assigned by the GHRSST Data And Systems Technical Advisory Group (DAS-TAG) and entered into the table upon agreement by the GDAC, LTSRF, and relevant RDACs.

4.5. <Processing Level>#

Satellite data processing level definitions can lead to ambiguous situations, especially regarding the distinction between L3 and L4 products. GHRSST identified the use of analysis procedures to fill gaps where no observations exist to resolve this ambiguity. Within GHRSST filenames, the <Processing Level> codes are shown below in Table 4.2. GHRSST currently establishes standards for L2P, L3U, L3C, L3S, and L4 (GHRSST Multi-Product Ensembles known as GMPE are a special kind of L4 product for which GHRSST also provides standards).

Table 4.2 GHRSST Processing Level Conventions and Codes#

Level

Code

Description

Level 0

L0

Unprocessed instrument and payload data at full resolution. GHRSST does not make recommendations regarding formats or content for data at this processing level.

Level 1A

L1A

Reconstructed unprocessed instrument data at full resolution, time referenced, and annotated with ancillary information, including radiometric and geometric calibration coefficients and geo-referencing parameters, computed and appended, but not applied, to L0 data. GHRSST does not make recommendations regarding formats or content for data at this processing level.

Level 1B

L1B

Level 1A data that have been processed to sensor units. GHRSST does not currently make recommendations regarding formats or content for L1B data.

Level 2 Pre-processed

L2P

Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates.

Level 3

L3U L3C L3S

Level 2 variables mapped on a defined grid with reduced requirements for ancillary data. Uncertainty estimates are still mandatory. Three types of L3 products are defined: Un-collated (L3U): L2 data granules remapped to a space grid without combining any observations from overlapping orbits Collated (L3C): observations combined from a single instrument into a space-time grid Super-collated (L3S): observations combined from multiple instruments into a space-time grid. Note that L3 GHRSST products do not use analysis or interpolation procedures to fill gaps where no observations are available.

Level 4

L4

Data sets created from the analysis of lower level data that result in gridded, gap-free products. SST data generated from multiple sources of satellite data using optimal interpolation are an example of L4 GHRSST products. GMPE products are a type of L4 dataset.

Note that within GHRSST, all L2P files require a full set of extensive ancillary data such as wind speeds and times of observation that are provided as ‘dynamic flags’ that users can manipulate to filter data according to their own quality criteria. L2P files form the basis of higher-level products and are often the best level products for data assimilation. The requirement for dynamic flags is particularly important in this context. Higher-level L3 products are often intended for general use or created for input to Level 4 analysis systems so the requirement for extensive ancillary data is reduced. Since some GHRSST RDACs only process data natively on grids (especially in the case of geostationary platform observations), the GDS 2.1r0 L3 specification is flexible enough to allow for the creation of L3 files which meet all the content requirements of a L2P file. In all L2P and L3 cases, bias and standard deviation uncertainty estimates are mandatory.

The distinction between L3 GHRSST and L4 GHRSST data is made primarily on whether or not any gap-filling techniques are employed, not on whether data from multiple instruments is used in the L3 product. If no gap filling procedure (such as optimal interpolation) is used, then the product remains a L3 GHRSST product. GHRSST defines three kinds of L3 files: un-collated (L3U), collated (L3C), and super-collated (L3S). If gap filling is used to fill all observations gaps, then the resulting gap-free data are considered L4 GHRSST data products.

4.6. <SST Type>#

In conjunction with the NetCDF Climate and Forecast (CF) community [AD-9] the GHRSST Science Team agreed on the CF standard names for “SST” shown in the following figure and described in more detail below. The names were first included in CF-1.3, and the current version of the standard name table can be found in [AD-8]. In addition, the GHRSST Science Team agreed to use the CF Naming Convention [AD-3] for variable names that do not already exist as part of the CF Convention. CF definitions are used in the GDS and across GHRSST and are shown schematically in Fig. 3.1. The different kinds of SST are detailed later in this section and the relevant <SST Type> codes to be used in the filenames are provided.

The SST codes and CF standard names defined above and used within GHRSST are summarized along with their key characteristics in Table 4.3.

Table 4.3 GHRSST SST Type code and summary table#

GHRSST SST Type

CF Standard Name

Approximate Depth

Typically Observed by…

SSTint

sea_surface_temperature

0 meters

Not presently measureable

SSTskin

sea_surface_skin_temperature

10 – 20 micrometers

Infrared radiometers operating in a range of wavelengths form 3.7 to 12 micrometers

SSTsubskin

sea_surface_subskin_temperature

1 – 1.5 millimetres

Microwave radiometers operating in a range of frequencies from 6-11 gigahertz

SSTdepth

sea_water_temperature

Specified by vertical coordinate (e.g., SST5m)

In situ observing systems

SSTfnd

sea_surface_foundation_temperature

1-5 meters pre-dawn

In situ observing systems

SSTblend

None

Unknown

Blend of satellite and in situ observations

4.7. <Product String>#

The product strings are used within the GHRSST filename convention and within the GHRSST unique data set codes described in Section 4.9. The satellite platform and satellite sensor entries are also used in the netCDF global attributes, platform and instrument GHRSST product files. See Section 5.2 for more information on the required global attributes.

In order to improve the consistency of these product strings across producers, and avoid maintaining specific GHRSST tables, we recommend to use the CEOS tables as vocabulary for satellite platform and satellite name:

Note

unfitted characters for file naming (like / or spaces) can be replaced with -.

The following code nomenclature is recommended for the single sensor products: <platform code>_<sensor code>(_<additional text if needed>)

As an example, a product string for a METOP-A AVHRR product would be : Metop-A_AVHRR-3

4.8. <Additional Segregator>#

It is possible for the preceding combination of filename components to result in a non-unique filename for any GHRSST product level. In those situations, the use of the <Additional Segregator> must be used to ensure each distinct file has a unique file name. In addition, RDACs are free to use this component to add other information to their file names. Some providers, for example, use the name of the original L1b file. Others enter start and stop times of the file in this component. Note that in the case of GHRSST L4 files the <Additional Segregator> element must begin with a code that specifies the approximate region covered by the SST analysis product. There are two primary reasons for this requirement, the first of which is to ensure uniqueness in the file names in the cases where an RDAC is using the same L4 analysis system (for example, “ODYSSEA”) to create products for multiple regions (for example, “GAL” (Galapagos Islands Region) and “MED” (Mediterranean Region)). The second reason is that users need to quickly identify at a glance the approximate domain of the L4 products. Users should note that the geographical coordinates associated with each area code are explicitly intended to be only approximate, and not strict. For example, an RDAC producing a near-global coverage data may choose to only produce data on a grid that extends to 85°S. Such a product would use the “GLOB” code. Users must retrieve the precise latitude and longitude limits directly from the L4 netCDF data files.

4.9. GHRSST Unique Text Strings and Numeric Codes#

This section describes the best practices that have been developed for creating unique text strings and numeric codes that are needed in various places within some GHRSST files. Note that these strings are not part of the filename convention described above, but, like filenames, they apply to all GHRSST product levels and so are described in this part of the GDS.

4.9.1. SST Variable Text Strings and Numeric Codes#

For each official GHRSST product, a unique numeric code and associated text string is defined. The string is listed in the global attribute id (see Section 8.2) for each netCDF file in the product collection. The unique numerical values and text strings for GHRSST SST datasets are established by agreement between the relevant RDAC, GDAC, and the LSTRF, following the Best Practice defined later in this section. The GHRSST L2P, L3, L4 and GMPE product specifications (Section 7, Section 8, Section 9, and 12, respectively) also require the providing RDAC to use these text strings directly within the netCDF global attribute source to indicate the sources of SST used to create the product. In the event that a non-GHRSST dataset is used as a source, as in the case of an L2P product that uses a Level 1 dataset as its source, it too must have an established text string following the best practice below (to the extent possible).

The associated numeric codes are used in some L3S files, which must describe the SST sources pixel-by-pixel in a variable named source_of_sst if more than one SST source is used. If only one source is used, the variable source_of_sst is not needed and instead the source is indicated simply by using the text string in the global attribute source (see Section 8.2 and Section 10.29) as indicated earlier.

4.9.2. Ancillary and Optional Variable Text Strings and Numeric Codes#

GHRSST L2P, L3, L4 and GMPE product specifications (Section 7, Section 8, Section 9, and 12, respectively) also require the providing RDAC to indicate text strings and associated numeric codes directly within the netCDF global and variable attributes for the sea surface temperature or ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, wind speed, and when relevant, for optional and experimental variables. These text strings and codes do not need to be unique across different data sets, but must be consistent within a given data set and clearly specified within each netCDF file. In these cases, the variable in question should contain an attribute called flag_meanings together with a variable called flag_values. The flag_values attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the flag_meanings attribute.

4.9.3. Best Practice for Establishing Character Strings#

A best practice has been established for defining the text strings to be used in these GHRSST attributes. While a rigid standard for the text strings is not possible, the following best practice should be applied to the extent possible for GHRSST SST datasets and the ancillary and optional variables:

<Product String>-<RDAC>-<Processing Level>-<Additional Segregator>-v<Product Version>

The definitions of the components match the definitions from the file naming convention, found in Table 4.1. The component <Product Version> is used to distinguish different versions of the same dataset and should be of the form x.y where x is the major and y is the minor version. For ancillary and optional variables, an attempt should be made to follow these conventions to the extent possible. If there is no appropriate GHRSST RDAC to use in the string, then it is recommended that a commonly used acronym for the centre responsible be used. It is recommended that the <Additional Segregator> should be one of ICE, ADI, CLIM, SSI, and WSP, for ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, and wind speed variables, respectively.

Notethat many SST text strings not meeting this best practice were established under the GDS version 1 and are already in use.

These codes are used in the GHRSST Central Catalogue as product identifiers.

objects.inv0000664000175000017500000000561314744715212013435 0ustar jfpiollejfpiolle# Sphinx inventory version 2 # Project: Project name not set # Version: # The remainder of this file is compressed using zlib. xڭ[n8}W<@w\ړĈ*-vjI!vz~xug{!M:U$bI}^>Շ;|bER%쮔=]]^IЌD_? 'Lrrp,oH*7eU`EJY&ҬdyH?PS ;b.KUiv*AlSQdbjeh+3feuʠW'% VS $,l?ǀ ƣt'xq8$w¿U\P5quGL *md<#'3ە,"_u[5eR9/^ Fi3MV`),[sFJ[hOv2ޫ.W1@3pU/#19s޼ =q#AcØ0ˉ8ZƅRsg|oPřqԀBL*k.G8*}l.< CҪƸ.4G $ƙ3'aNڮ BJ8Vlg2 ಪ&?D #t a٨>ŠUNp2-1<*R1>J"1WIZ;.y3;V-i]R֣m"3MlYJZQoa)~aAy#mҟKESDS JeaǰzpƵ[}LO{ '#w|mY2JK-dlI}8N@XҀs hpzM +c68 Ki_=3›h+r[? {uDžSmygklj4xp!y/2Z}y?\őv~s-j|:"R s * jYH<}0~H> 3+;c\t%WXUE|E=vQWƆ$ &&E'.EBw_Ard?inz[|HdWrsvvSV OI)ezֳ&:jaa??0yI-:*ms?,};bayp!AcddTC KOhkSq=ԋ[j;0"3r2ܵS#K|EN [}y0pc.P|ugˁ\'NQҡ)s] (g+4 ,A<8X4;2d>D@4JC9:gyDPy1~wQOrtEtvtt-xMDRdX]Jb+Ԡ:k }XbĿ[-1(CN2IBCw0 OU~qXX,縱 CPmlҊY"aQYOctֵj>Zϊl=OĻm{tdY$-f"{jvLJ"ݨʱ~S3=yc7p$XOgWq/[/A_Z^eІ3J s=GzsyDhX!`igA>=%bOc/1PODY1OPt_Z_#x;vD.ŀ}vHt&P/\XX#?Q ˤGWcKj1EׂaGC`b/ICy&Kjk;H:Q,O0@nٶ,L xnMUR}X#q/EHQ+EQZ)w±RU#ngG"3.LI#k ^f`KceZ{iQRKշ3-W5+2^0xU=jTR< k3!]p&mz9PJ7J[+Zbj" m%X2Z 3[-Z۾w vcl)ÚB|m8yƽ.hK o`K*,O`iݩ~.Ww 7x1W%y' qt8VlDdd"eSWMJ{1Uc2>hȫE(r.uPjmf9 G=2|cebk t7%pI~ϥd3ܠx kMTogiQ ^ȿ\l0+GY-oh<j\;r ׃z~yzwCh9 [>1! ޽m^`vv {KϾ]'MNYlàarF"MAM,Ǥ0TK Mnӫ~z҇#h[?RjYuԋm^Q$c(kD?D/ :nyJ}S6hqWhxf"Q Y/w7A=j+`?"֍d A&j{Ә O":pe̓ufn,overview.html0000664000175000017500000011527414744715212014027 0ustar jfpiollejfpiolle 2. Overview of GHRSST and the GDS-2.1r0 — The Recommended GHRSST Data Specification (GDS)

2. Overview of GHRSST and the GDS-2.1r0#

GHRSST [1] is an international consortium representing commercial enterprises, academic institutions, research organizations, and operational agencies that collaborate to provide accurate, high resolution, and consistently formatted SST observations and analyses from space-based platforms.

This section briefly provides information on the importance of SST, an overview and history of GHRSST, and context for understanding the GDS-2.1r0.

2.1. The Importance of SST#

Sea Surface Temperature at the ocean-atmosphere interface is a fundamental variable for understanding, monitoring, and predicting fluxes of heat, momentum, and gas at a variety of scales that determine complex interactions between atmosphere and ocean. The ocean stores heat from the sun and redistributes it from the tropical regions to higher latitudes and to the less dense atmosphere regulating global weather and climate. Through the hydrological cycle the coupled system controls terrestrial life by redistributing fresh water over the land surface. From large ocean gyres and atmospheric circulation cells that fuel atmospheric depression systems, storms and hurricanes with their attendant wind waves and storm surges, to local scale phenomena such as the generation of sea breezes and convection clouds, SST at the ocean-atmosphere interface has a significant societal impact. Accurate knowledge of global SST distribution and temporal variation at finer spatial resolution is needed as a key input to numerical weather prediction (NWP) and numerical ocean prediction (NOP) systems to constrain the modelled upper-ocean circulation and thermal structure at daily, seasonal, decadal, and climatic time scales, for the exchange of energy between the ocean and atmosphere in coupled ocean-atmosphere models, and as boundary conditions for ocean forecasting models. Such models are widely used operationally for various applications including maritime safety, military operations, ecosystem assessments, fisheries support, and tourism.

In addition, well-defined and quantified error estimates of SST are also required for climate time series that can be analysed to reveal the role of the ocean in short and long term climate variability. A 30 year record of satellite SST observations is available now, that grows on a daily basis. SST climate data records that are used to provide the GCOS SST Essential Climate Variable (ECV) [2], [3], [4] are essential to monitoring and understanding climate variability, climate-ecosystem interactions such as coral reef health and sustainable fisheries management, and critical issues like sea level rise and changing sea ice patterns.

2.2. GHRSST History#

In 1998, SST data production was considered a mature component of the observing system with demonstrated capability and data products. However, SST product availability was limited to a few data sets that were large, scientific in format and difficult to exchange in a near real time manner. Product accuracy was considered insufficient for the emerging NWP and NOP systems. Uncertainty estimates for SST products were unavailable with SST products complicating their application by the NWP and NOP data assimilation community. At the same time the number of applications requiring an accurate high resolution SST data stream was growing.

Considering these issues, the Global Ocean Data Assimilation Experiment (GODAE) [[5]] defined the minimum data specification required for use in operational ocean models, stating that SST observations with global coverage, a spatial resolution of 10 km and an accuracy of <0.4 K need to be updated every six hours [[5]].

Despite the network of SST observations from ships and buoys, the only way to achieve these demanding specifications was to make full use of space-based observations. An integrated and international approach was sought to improve satellite SST measurements, based on four principles:

  • Respond to user SST requirements through a consensus approach,

  • Organize activities according to principles of shared responsibility and subsidiarity, handling matters with the lowest, smallest, or least centralized competent group possible,

  • Develop complementarities between independent measurements from earth observation satellites and in situ sensors,

  • Maximize synergy benefits of an integrated SST measurement system and end-to-end user service.

These foundations enabled the international ocean remote sensing community, marine meteorologists, Space Agencies, and ocean modellers to combine their energies to meet the GODAE requirements by establishing the GODAE High Resolution Sea Surface Temperature Pilot Project (GHRSST-PP). GHRSST-PP established four main tasks relevant to the development of the SST observing system:

  • Improve SST data assembly/delivery,

  • Test available SST data sources,

  • Perform inter-comparison of SST products,

  • Develop applications and data assimilation of SST to demonstrate the benefit of the improved observing system.

GHRSST-PP successfully demonstrated that the requirements of GODAE could be met when significant amounts of GHRSST-PP data became available in 2006 and was instrumental in defining the shape and form of the modern-era SST measurement system and user service over the last 10 years [1].

At the end of the GODAE period in 2009, the GHRSST-PP evolved into the Group for High Resolution SST (GHRSST). GHRSST built on the successes of the pilot project phase and continued a series of international workshops that were held during 2000-2009. These workshops established a set of user requirements for all GHRSST activities in five areas:

  • Scientific development and applications,

  • Operational agency requirements,

  • SST product specifications,

  • Programmatic organization of an international SST service,

  • Developing scientific techniques to improve products and exploit the observing system.

These requirements were critical to establishing the GHRSST framework and work plan and formed an essential part of the GHRSST evolution. By establishing and documenting clear requirements in a consultative manner at the start of the project and through all stages of its development, GHRSST was able to develop confidently and purposefully to address the needs of the international SST user community.

2.3. GHRSST Organization#

Over the last two decades, GHRSST established and now continues to provide an internationally distributed suite of user focused services in a sustained Regional/Global Task Sharing (R/GTS) framework [AD-11] that addresses international organizational challenges and recognizes the implementing institutional capacities, capabilities, and funding prospects. Long term stewardship, user support and help services, and standards-based data management and interoperability have been developed and are operated within the R/GTS on a daily basis. The first GHRSST Level 2P datasets were made available in 2006. Since then the GHRSST R/G TS framework did not change up to 2019. Datasets produced from the collection of international 14 Regional Data Assembly Centres (RDACs) were ingested by a Global Data Assembly Centre (GDAC), such as the US GDAC located at the NASA Jet Propulsion Laboratory, Physical Oceanography Active Archive Data Center PO.DAAC). These data were made available for public distribution via a number of access protocols, tools and services, and also staged for ingestion. Final archiving and further distribution services were performed by the Long-term Stewardship and Reanalysis Facility (LTSRF) located at the NOAA National Center for Environmental Information (NCEI). This initial GHRSST R/G TS Framework is presented in Figure 6-1.

Although this initial paradigm has functioned well, it has deviated from its initial design with the growing number of producers and datasets. As seen in the dashed box in Figure, a new GDAC was set-up in Europe, delivering products not available at the US GDAC, while other producers (e.g. CMEMS, Copernicus/EUMETSAT, and JAXA) are also now delivering products through their own services without any push to a GDAC. It was recognized by the GHRSST data management experts, through discussions from 2017 to 2019, and confirmed at the annual GHRSST science team meetings, that a more defined sharing of data management resources would be beneficial to the future growth of GHRSST and encourage more participation by other potential data producers. The specification of the GHRSST data management paradigm for the next years is the focus of the next sections. It can be summarised by a more distributed system where no entity, but the GHRSST Project Office, plays a central role anymore, as shown on Figure 6-2. In the new R/G TS framework, there are now only two types of entities: data producers (GDP or GHRSST Data Producers) and distributing centres (DAC or Data Assembly Centre). The two roles can be combined by a single institution (for example, EUMETSAT which produces and delivers Sentinel-3 A & B products). The GHRSST Project Office (GHRSST-PO) provides and maintains on its portal a central catalogue of all GHRSST datasets providing collection (dataset) level metadata, and federated search and discovery services. Each DAC must implement a minimum set of services for granule data access, search and discovery, production/distribution metrics and long-term archiving.

Figure 6-2: Revised architecture proposal. Multiple interfaces are now available to data producers. Each data node implements interface, distribution, archiving and metadata services for the datasets they are responsible for. Data and metadata from data producers (GDPs) flow first to a DAC (like PO.DAAC, before as the US GDAC). There is no more GDAC with the commitment to host all GHRSST datasets, it is now a shared task between DACs and some datasets can be distributed by several DACs. The GHRSST-PO portal allows the user to discover and search all GHRSST products and granules without prior knowledge of who is the producer or distributor.

Each component of the R/GTS is independently managed and operated by different institutions and agencies. The R/GTS itself is coordinated by the international GHRSST Science Team, which receives guidance and advice from the GHRSST Advisory Council. A GHRSST Project Office coordinates the overall framework.

2.4. Overview of the GDS-2.1#

The GHRSST R/GTS was made possible through the establishment of a rigorous GHRSST Technical Data Specification (GDS), which instructed international satellite data providers on how to process satellite data streams, defined the format and content of the data and metadata, and documented the basic approaches to providing uncertainty estimates and auxiliary data sets. The GHRSST-PP established the first GDS (v1.6) [RD-1], which formed the basis of all GHRSST data production from 2005 through today. Since 2010 the Version 2 of the GDS has been used in operations, with minor updates occurring from time to time. All GHRSST products entering the R/GTS must strictly follow the common GDS when generating L2P, L3, L4, and GMPE data. As a result, users with common tools to read data from one RDAC can securely use data from any of the others as well as the GDAC and LTSRF without a need to re-code. Table 6-1 provides a summary of GDS-2.1 data products and their basic characteristics. The remainder of this document provides the detailed specifications for GHRSST L2P, L3, L4, and GMPE products, their file naming convention, metadata requirements, and all necessary tables, conventions, and best practices for creating and using GHRSST data.

SST Product

L2 Pre-Processed Section 7

L3 Uncollated [Section 1010]

L3 Collated[Section 10]

L3 Super-collated[Section 10]

Analyzed SST[Section 11]

Acronym

L2P

L3U

L3C

L3S

L4

Description

Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates. No adjustments to input SST have been made.

L2 data granules remapped to a space grid without combining any observations from overlapping orbits.

SST measurements combined from a single instrument into a space-time grid.

Multiple passes/scenes of data can be combined. Adjustments may be made to input SST data.

SST measurements combined from multiple instruments into a space-time grid. Multiple passes/scenes of data are combined. Adjustments may be made to input SST data.

Grid specification

Native to SST data format

Defined by data provider

Defined by data provider

Defined by data provider

Defined by data provider

Temporal resolution

Native to SST data stream

Native to data stream

Defined by data provider

Defined by data provider

Defined by data provider

Delivery timescale

As available, Ideally within 3 hours from acquisition at satellite

As available, Ideally within 3 hours from acquisition at satellite

As available, Ideally within 3 hours from acquisition at satellite

As available, Ideally within 3 hours from acquisition at satellite

Analyzed product processing window as defined by data provider.

Target accuracy

Native to data stream

Native to data stream

<0.4 K

<0.4 K

< 0.4 K absolute, 0.1 K relative

Error statistics

Native to data stream if available, sensor specific error statistics otherwise

Native to data stream if available, sensor specific error statistics otherwise

Derived from input data for each output grid point.

Derived from input data for each output grid point.

Analysis error defined by data provider for each output grid point (no input data statistics are retained)

Coverage

Native to data stream

Native to data stream

Defined by data provider

Defined by data provider

Defined by data provider

L3 GHRSST products do not use analysis or interpolation procedures to fill gaps where no observations are available


search.html0000664000175000017500000003400314744715212013414 0ustar jfpiollejfpiolle Search - The Recommended GHRSST Data Specification (GDS)

Search

searchindex.js0000664000175000017500000016165014744715212014125 0ustar jfpiollejfpiolleSearch.setIndex({"alltitles": {"": [[6, "additional-segregator"]], "": [[6, "indicative-date"]], "": [[6, "indicative-time"]], "": [[6, "processing-level"]], "": [[6, "product-string"]], "": [[6, "rdac"]], "": [[6, "sst-type"]], "Additional Details:": [[8, null], [8, null], [8, null], [8, null]], "Additional details": [[8, null]], "Ancillary and Optional Variable Text Strings and Numeric Codes": [[6, "ancillary-and-optional-variable-text-strings-and-numeric-codes"]], "Best Practice for Establishing Character Strings": [[6, "best-practice-for-establishing-character-strings"]], "Best Practices": [[4, "best-practices"]], "CDL example L2P dataset": [[3, "cdl-example-l2p-dataset"]], "CDL example L4 dataset": [[5, "cdl-example-l4-dataset"]], "CDL example description of adi_dtime_from_sst variable": [[3, "id14"]], "CDL example description of adjusted_sea_surface_temperature variable": [[4, "id6"]], "CDL example description of adjusted_standard_deviation_error variable": [[4, "id7"]], "CDL example description of aerosol_dynamic_indicator variable": [[3, "id13"]], "CDL example description of analysed_sst variable": [[5, "id1"]], "CDL example description of analysis_error variable": [[5, "id2"]], "CDL example description of bias_to_reference_sst variable": [[4, "id8"]], "CDL example description of dt_analysis variable": [[3, "id6"]], "CDL example description of mask variable": [[5, "id4"]], "CDL example description of or_latitude variable": [[4, "id1"]], "CDL example description of or_longitude variable": [[4, "id2"]], "CDL example description of or_number_of_pixels variable": [[4, "id3"]], "CDL example description of quality_level variable": [[3, "id17"]], "CDL example description of satellite_zenith_angle variable": [[3, "id18"]], "CDL example description of sea_ice_fraction variable": [[3, "id10"], [5, "id3"]], "CDL example description of sea_ice_fraction_dtime_from_sst variable": [[3, "id11"]], "CDL example description of sea_ice_fraction_error variable": [[5, "id5"]], "CDL example description of sea_surface_temperature variable": [[3, "id1"]], "CDL example description of solar_zenith_angle variable": [[3, "id19"]], "CDL example description of source_of_adi variable": [[3, "id15"], [3, "id16"]], "CDL example description of source_of_sea_ice_fraction variable": [[3, "id12"]], "CDL example description of source_of_ssi variable": [[3, "id22"]], "CDL example description of source_of_sst variable": [[4, "id10"]], "CDL example description of source_of_wind_speed variable": [[3, "id9"]], "CDL example description of sses_bias variable": [[3, "id4"]], "CDL example description of sses_standard_deviation variable": [[3, "id5"]], "CDL example description of ssi_dtime_from_sst variable": [[3, "id21"]], "CDL example description of sst_dtime variable": [[3, "id3"]], "CDL example description of standard_deviation_to_reference_sst variable": [[4, "id9"]], "CDL example description of sum_square_sst variable": [[4, "id5"]], "CDL example description of sum_sst variable": [[4, "id4"]], "CDL example description of surface_solar_irradiance variable": [[3, "id20"]], "CDL example description of wind_speed variable": [[3, "id7"]], "CDL example description of wind_speed_dtime_from_sst variable": [[3, "id8"]], "CDL template for data provider defined L2P variables": [[3, "l2p-experimental"]], "Collating Data from the Same Sensor and Platform": [[4, "collating-data-from-the-same-sensor-and-platform"]], "Comments:": [[5, null]], "Coordinate variables": [[1, null]], "Definition of text styles used in the GDS": [[0, "text-styles"]], "Definitions of storage types": [[0, "definitions-of-storage-types"]], "Document Conventions": [[0, null]], "Example CDL for Non-regular latitude/longitude grids (projections) alternative form with no explicit latitudes/longitudes": [[1, "non-regular-grid-coords-projection-no-latlon"]], "Example CDL for geographic regular latitude/longitude grids": [[1, "regular-grid-coords"]], "Example CDL for non-regular latitude/longitude grids (projection)": [[1, "non-regular-grid-coords-projection"]], "Example CDL for non-regular latitude/longitude grids (swath)": [[1, "non-regular-grid-coords"]], "Example text string and numeric codes used to identify the sources of data in surface_solar_irradiance:sources and source_of_ssi": [[3, "l2p-source-of-ssi-codes"]], "Filenaming convention components.": [[6, "filenaming-components"]], "GDS Data Product File Structure and attributes": [[9, null]], "GDS Filenames and Supporting Conventions": [[6, null]], "GHRSST History": [[7, "ghrsst-history"]], "GHRSST Organization": [[7, "ghrsst-organization"]], "GHRSST Processing Level Conventions and Codes": [[6, "id4"]], "GHRSST SST Type code and summary table": [[6, "sst-types"]], "GHRSST Unique Text Strings and Numeric Codes": [[6, "ghrsst-unique-text-strings-and-numeric-codes"]], "GHRSST short SST names and CF-1.7 standard names for sea_surface_temperature": [[3, "sst-standard-names"]], "Global Attributes": [[9, "global-attributes"]], "L2P data record format specification": [[3, "l2p-data-record-format-specification"]], "L3 data record format specification": [[4, "l3-data-record-format-specification"]], "L4 SST product data records": [[5, "l4-records"]], "L4 data record format specification": [[5, "l4-data-record-format-specification"]], "Level 2 Pre-processed (L2P) Product Specification": [[3, null]], "Level 3 (L3) Product Specification": [[4, null]], "Level 4 (L4) Product Specification": [[5, null]], "List of bits composing the l2P_flags variable": [[3, "l2p-flags-bits"]], "Mandatory global attributes for GDS-2.1r0 netCDF data files (blue are mandatory, purple are optional)": [[9, "id6"]], "Non-regular latitude/longitude grids (projection)": [[1, "non-regular-latitude-longitude-grids-projection"]], "Non-regular latitude/longitude grids (projection) \u2013 alternative without explicit latitude/longitude": [[1, "non-regular-latitude-longitude-grids-projection-alternative-without-explicit-latitude-longitude"]], "Non-regular latitude/longitude grids (swath)": [[1, "non-regular-latitude-longitude-grids-swath"]], "Note on lat/lon arrays": [[1, null]], "Optional Variable sea_ice_fraction_error": [[5, "optional-variable-sea-ice-fraction-error"]], "Optional experimental L2P variables included by data provider": [[3, "optional-experimental-l2p-variables-included-by-data-provider"]], "Optional experimental L4 variables included by data provider": [[5, "optional-experimental-l4-variables-included-by-data-provider"]], "Overview description of the GHRSST L2P data product": [[3, "overview-description-of-the-ghrsst-l2p-data-product"]], "Overview description of the GHRSST L3 data product": [[4, "overview-description-of-the-ghrsst-l3-data-product"]], "Overview description of the GHRSST L4 data product": [[5, "overview-description-of-the-ghrsst-l4-data-product"]], "Overview of Filename Convention and Example Filenames": [[6, "overview-of-filename-convention-and-example-filenames"]], "Overview of GHRSST and the GDS-2.1r0": [[7, null]], "Overview of the GDS-2.1": [[7, "overview-of-the-gds-2-1"]], "Overview of the GDS-2.1r0 netCDF File Format": [[9, "overview-of-the-gds-2-1r0-netcdf-file-format"]], "Reference SST data sets for use in dt_analysis computation": [[3, "l2p-dt-analysis-code"]], "Regular latitude/longitude grids": [[1, "regular-latitude-longitude-grids"]], "Remapping Level 2 Data to a Fixed Grid": [[4, "remapping-level-2-data-to-a-fixed-grid"]], "SST Adjustments": [[4, "sst-adjustments"]], "SST Variable Text Strings and Numeric Codes": [[6, "sst-variable-text-strings-and-numeric-codes"]], "Sample GHRSST L3 file (CDL header)": [[4, "sample-ghrsst-l3-file-cdl-header"]], "Sea Surface Temperature": [[8, null]], "Spatial coordinates": [[1, "spatial-coordinates"]], "Storage type definitions used in the GDS": [[0, "colour-styles"], [0, "storage-types"]], "Summary description of GHRSST L2P data records": [[3, "l2p-variables"], [4, "l3-data-records"]], "Summary description of the contents of a GHRSST L2P data product": [[3, "l2p-content-summary"]], "Summary description of the contents within a GHRSST L3 data product": [[4, "l3-content"]], "Summary description of the contents within a GHRSST L4 data product": [[5, "l4-content-summary"]], "Super-Collating Data from Multiple Sensors and Platforms": [[4, "super-collating-data-from-multiple-sensors-and-platforms"]], "Temporal coordinates": [[1, "temporal-coordinates"]], "The Importance of SST": [[7, "the-importance-of-sst"]], "The Recommended GHRSST Data Specification (GDS) Version 2.1r0": [[2, null]], "Use of colour in tables": [[0, "use-of-colour-in-tables"]], "Use of text types": [[0, "use-of-text-types"]], "Variable Attributes": [[9, "variable-attributes"]], "Variable attributes for GDS-2.1 netCDF data files (blue are mandatory, purple are optional, orange are deprecated attributes from previous GDS versions)": [[9, "var-attributes"]], "adi_dtime_from_sst": [[3, "adi-dtime-from-sst"]], "adjusted_sea_surface_temperature": [[4, "adjusted-sea-surface-temperature"]], "adjusted_standard_deviation_error": [[4, "adjusted-standard-deviation-error"]], "aerosol_dynamic_indicator": [[3, "aerosol-dynamic-indicator"]], "analysed_sst": [[5, "analysed-sst"]], "analysis_error": [[5, "analysis-error"]], "bias_to_reference_sst": [[4, "bias-to-reference-sst"]], "dt_analysis": [[3, "dt-analysis"]], "l2p_flags": [[3, "l2p-flags"]], "mask": [[5, "mask"]], "or_latitude": [[4, "or-latitude"]], "or_longitude": [[4, "or-longitude"]], "or_number_of_pixels": [[4, "or-number-of-pixels"]], "quality_level": [[3, "quality-level"]], "satellite_zenith_angle": [[3, "satellite-zenith-angle"]], "sea_ice_fraction": [[3, "sea-ice-fraction"], [5, "sea-ice-fraction"]], "sea_ice_fraction_dtime_from_sst": [[3, "sea-ice-fraction-dtime-from-sst"]], "sea_surface_temperature": [[3, "sea-surface-temperature"]], "solar_zenith_angle": [[3, "solar-zenith-angle"]], "source_of_adi": [[3, "source-of-adi"]], "source_of_sea_ice_fraction": [[3, "source-of-sea-ice-fraction"]], "source_of_ssi": [[3, "source-of-ssi"]], "source_of_sst": [[4, "source-of-sst"]], "source_of_wind_speed": [[3, "source-of-wind-speed"]], "sses_bias": [[3, "sses-bias"]], "sses_standard_deviation": [[3, "sses-standard-deviation"]], "ssi_dtime_from_sst": [[3, "ssi-dtime-from-sst"]], "sst_dtime": [[3, "sst-dtime"]], "standard_deviation_to_reference_sst": [[4, "standard-deviation-to-reference-sst"]], "sum_square_sst": [[4, "sum-square-sst"]], "sum_sst": [[4, "sum-sst"]], "surface_solar_irradiance": [[3, "surface-solar-irradiance"]], "wind_speed": [[3, "wind-speed"]], "wind_speed_dtime_from_sst": [[3, "wind-speed-dtime-from-sst"]]}, "docnames": ["conventions", "coordinates", "intro", "l2p", "l3", "l4", "naming", "overview", "sea_surface_temperature", "structure"], "envversion": {"sphinx": 62, "sphinx.domains.c": 3, "sphinx.domains.changeset": 1, "sphinx.domains.citation": 1, "sphinx.domains.cpp": 9, "sphinx.domains.index": 1, "sphinx.domains.javascript": 3, "sphinx.domains.math": 2, "sphinx.domains.python": 4, "sphinx.domains.rst": 2, "sphinx.domains.std": 2, "sphinx.ext.intersphinx": 1, "sphinxcontrib.bibtex": 9}, "filenames": ["conventions.md", "coordinates.md", "intro.md", "l2p.md", "l3.md", "l4.md", "naming.md", "overview.md", "sea_surface_temperature.md", "structure.md"], "indexentries": {}, "objects": {}, "objnames": {}, "objtypes": {}, "terms": {"": [1, 3, 4, 5, 6, 7, 9], "0": [1, 3, 4, 5, 6, 7, 9], "00": [1, 3, 4, 5, 6, 9], "00000000": 9, "00000001": 9, "00000010": 9, "00000100": 9, "00000101": 9, "00001000": 9, "00010000": 9, "001": 5, "00100000": 9, "00164": 4, "00321": 5, "005f": 9, "0075f": 9, "00f": 9, "00z": [4, 5], "01": [1, 3, 4, 5, 6, 9], "010": [4, 5], "01t00": [4, 5], "01t08": 9, "01t12": 4, "02": [4, 5, 6], "03": [5, 6], "043": 5, "04z": 4, "05t16": 5, "09": 9, "09f": 9, "0b": [3, 4], "0cc47a3fe28f": 4, "0f": 9, "0ll": 4, "1": [0, 1, 4, 5, 6, 8], "10": [1, 3, 4, 5, 6, 7, 8, 9], "100": 9, "1000": [1, 9], "1010": 7, "1024": 0, "10km": 4, "10m": [3, 9], "11": [3, 4, 5, 6, 7, 8, 9], "110": 9, "111": 9, "1143": 7, "1175": 7, "1197": 7, "11ee": 4, "12": [3, 4, 5, 6, 8, 9], "1213": 7, "1219": 7, "127": [3, 9], "127b": 4, "128": 9, "128b": [3, 4, 5], "129": 9, "13": [3, 6], "14": [3, 7], "1404": 9, "1404f": 9, "143": 9, "14t21": 9, "14th": 3, "15": [1, 3, 4, 5, 7, 9], "151844f": 1, "15f": 9, "15t10": 4, "16": [0, 3, 4, 5], "1600": [4, 5], "16b": 9, "17": [3, 6, 9], "170": 9, "175": 9, "18": [3, 4, 5], "180": [1, 3, 4, 5, 9], "1800": 1, "1801": 1, "19": 3, "19115": [6, 9], "1981": [1, 3, 4, 5], "1998": 7, "1a": 6, "1b": [3, 5, 6, 9], "1km": 9, "1ll": 4, "1m": 9, "1r0": [1, 3, 4, 5, 6], "2": [0, 1, 5, 6], "20": [3, 4, 5, 6, 8], "200": 1, "2000": 7, "2002": 7, "2003": [5, 7], "2004": [7, 9], "2005": [3, 7], "2006": 7, "2007": [6, 7], "20070503110153": 6, "20070503120000": 6, "20070503132300": 6, "2009": 7, "2010": 7, "2014": 5, "2016": 9, "2017": 7, "2018": 9, "2019": 7, "2022": 5, "2023": [4, 5], "2024": [4, 5], "20240101000000": 4, "20b": 4, "20f": 4, "20th": 3, "21": 3, "2147483648": 4, "21b": 4, "22": 3, "23": [3, 5, 6], "24": [3, 4, 5], "240": 6, "24h": 4, "25": [3, 9], "2527ec2f": 5, "255": 9, "256": 9, "257223563": [1, 4], "26": [3, 9], "27": 3, "273": [1, 3, 4, 5, 9], "28": [3, 5, 9], "28t12": 5, "29": [6, 9], "298": [1, 4], "29t12": 5, "2b": [3, 5, 9], "2d": 9, "2km": 4, "2ll": 4, "2nd": 8, "2p": [2, 7, 8, 9], "2po28": 3, "3": [0, 1, 2, 3, 5, 6, 7, 8, 9], "30": 7, "300": 4, "31": 6, "314245": 1, "31t12": 4, "32": [0, 3], "32767": [1, 9], "32768": [1, 3, 4, 5], "32b": 9, "33": 9, "3400": 9, "353": 7, "35786023": 1, "36": [3, 9], "360": 9, "3600": [1, 4, 5], "369": 7, "3a": [4, 5], "3b": [3, 4, 5], "3d": 9, "3ll": 4, "3rd": 8, "4": [1, 2, 3, 4, 6, 7, 8, 9], "40": 9, "40000": 1, "4047": 9, "40d3": 5, "41": 9, "41b": 4, "42b": 4, "4326": [4, 5, 9], "44b0": 9, "4500": 4, "48670": [4, 5], "4979": 9, "4b": [3, 5, 9], "4ll": 4, "5": [3, 4, 5, 6, 7, 8, 9], "5000": 1, "5067": 3, "52b": 4, "53": 6, "53b": 4, "54": 4, "5703": 9, "5829": 9, "5831": [4, 5, 9], "59": [4, 5, 6, 9], "5b": [3, 4, 9], "5ll": 4, "5m": 8, "6": [1, 3, 4, 5, 6, 7, 8, 9], "60b": 4, "63": 9, "6356752": 1, "6378137": [1, 4], "64": [0, 3], "6b": 3, "6th": 3, "7": [1, 4, 5, 6, 7, 8, 9], "70b": 4, "72b": 4, "7432": 9, "7432f": 9, "75": 1, "79757ce8574f": 5, "7b": 3, "7b02": 9, "8": [0, 3, 4, 6, 7, 9], "80": [4, 5], "80b": 4, "81b": 4, "82": 7, "84": 1, "85": 6, "85b": 4, "8601": [4, 5, 9], "88": [7, 9], "88ca": 4, "893": 9, "893f": 9, "8b": [5, 9], "8d70": 5, "9": [3, 4, 5, 6, 8, 9], "90": [1, 3, 4, 5], "92": 7, "942b": 9, "A": [1, 2, 3, 4, 5, 6, 7, 8, 9], "AND": 9, "And": 6, "As": [1, 3, 4, 6, 7, 9], "At": [3, 7], "By": [3, 7], "For": [1, 2, 3, 4, 6, 8, 9], "If": [1, 3, 4, 5, 6, 8, 9], "In": [1, 2, 3, 4, 5, 6, 7, 8, 9], "It": [1, 3, 4, 5, 6, 7, 8, 9], "Its": [6, 9], "Near": [3, 4], "No": [1, 3, 7], "Not": 6, "On": 1, "One": 9, "Or": 4, "Such": [6, 7], "That": 9, "The": [0, 1, 3, 4, 5, 6, 8, 9], "Their": 4, "Then": 3, "There": [1, 3, 4, 6, 7, 9], "These": [1, 3, 4, 5, 6, 7, 9], "To": [4, 9], "_": [5, 6], "_analysi": 3, "_fillvalu": [1, 3, 4, 5, 9], "_fillvlalu": 9, "_ghrsst": 6, "a5f14cfc": 4, "a_avhrr": 6, "aatsr": 4, "abbrevi": 8, "abi": [4, 5], "abi_g18": [4, 5], "abl": [4, 7, 8], "aboard": 8, "about": 9, "abov": [3, 4, 6, 8, 9], "abscissa": 1, "absenc": [3, 8], "absolut": 7, "absorb": 3, "abstract": 9, "ac": 9, "academ": 7, "accept": 9, "acceptable_qu": [3, 4], "access": [2, 5, 7, 9], "accord": [1, 3, 4, 6, 7], "accordingli": 4, "account": [4, 6, 8], "accumul": 4, "accur": 7, "accuraci": [3, 7], "acdd": [4, 5, 9], "achiev": [6, 7, 8], "acknowledg": [4, 5, 9], "acquisit": [3, 7], "acronym": [6, 7], "across": [1, 3, 4, 6, 8], "act": 9, "activ": [2, 7, 9], "actual": 8, "ad": [1, 3, 4, 6, 7, 9], "add": [3, 6, 9], "add_offset": [1, 3, 4, 5, 9], "addit": [2, 3, 4, 5, 7, 9], "address": [7, 9], "adequ": [3, 5], "adequaci": 7, "adher": 0, "adi": [3, 6], "adi_dtime_from_sst": 4, "adjust": [1, 3, 7], "admit": 3, "adopt": [2, 4, 8, 9], "advantag": 9, "advic": 7, "advisori": [6, 7], "aerosol": [3, 4, 6], "aerosol_dyanamic_ind": 3, "aerosol_dynamic_ind": 4, "aerosol_sst_dtime_from_sst": 3, "affect": 3, "after": [1, 3, 4, 9], "agenc": 7, "aggreg": 1, "agre": [3, 6, 8], "agreement": [6, 8], "ahi": [4, 5], "ahi_h09": [4, 5], "aim": 4, "air": [3, 8], "algorithm": [4, 6, 9], "all": [1, 2, 3, 4, 5, 6, 7, 8, 9], "alloc": 4, "allow": [1, 3, 4, 5, 6, 7, 9], "along": [1, 6, 8], "alreadi": 6, "also": [1, 2, 3, 4, 5, 6, 7, 8, 9], "although": [1, 3, 4, 7], "altitud": 9, "am": 7, "ambigu": [6, 8, 9], "among": 4, "amount": [3, 5, 7], "amsr": [3, 4, 5], "amsr2": [4, 5], "an": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], "analog": 9, "analys": [4, 5, 7], "analysed_sst": 0, "analysi": [1, 2, 3, 4, 5, 6, 7, 8, 9], "analyz": [5, 7], "ancillari": [2, 3, 4, 5, 7, 9], "angl": [1, 3, 4], "angular_degre": [3, 4], "ani": [1, 2, 3, 4, 5, 6, 7, 8, 9], "annex": 9, "annot": 6, "annual": 7, "anomali": [3, 5], "anoth": [3, 4], "antimeridian": 9, "anymor": [1, 7], "anywai": 9, "aod": 3, "api": [3, 5], "appar": 3, "appear": 3, "append": [6, 9], "appendix": [1, 9], "appli": [1, 3, 4, 6, 9], "applic": [2, 3, 4, 5, 6, 7, 8, 9], "approach": [3, 4, 7], "appropri": [3, 4, 5, 6, 9], "approv": [3, 8], "approxim": [1, 4, 6, 8, 9], "april": 7, "ar": [0, 1, 2, 3, 4, 5, 6, 7, 8], "arabian": 3, "arbitrari": 9, "architectur": [2, 7], "archiv": [3, 5, 7, 9], "area": [3, 5, 6, 7], "argument": [1, 9], "arial": 0, "arino": 7, "aris": 8, "armstrong": 7, "around": 3, "arrai": 9, "arrang": 3, "ascat": 3, "ascend": 3, "aspect": 5, "aspx": [6, 9], "assembli": [6, 7], "assess": [3, 7], "assign": [3, 4, 6, 9], "assimil": [3, 6, 7], "assist": 3, "associ": [1, 3, 4, 5, 6, 8, 9], "assum": [3, 8, 9], "atlant": 3, "atmospher": [2, 3, 4, 7, 8, 9], "attach": [8, 9], "attempt": [6, 8], "attend": 7, "attribut": [0, 1, 2, 3, 4, 5, 6, 8], "attribute_convention_for_data_discovery_1": 9, "audienc": 9, "audit": 9, "author": [4, 5, 9], "automat": 1, "autret": [4, 5], "auxiliari": [3, 4, 5, 7, 9], "auxiliaryinform": [3, 4, 5, 9], "avail": [3, 4, 5, 6, 7, 9], "averag": [1, 3, 4, 5, 9], "avhrr": [1, 4, 5, 6], "avhrr17_l": 6, "avhrr_metop_c": 3, "avhrr_sst_metop_b": [4, 5], "avhrr_sst_metop_c": [4, 5], "avoid": [4, 6, 9], "ax": 1, "axi": [1, 4, 5, 8, 9], "b": [3, 4, 5, 7], "b38f": 4, "b56c": 5, "b6ac7651": 9, "bad_data": [3, 4], "balanc": 8, "bam": 7, "band": [3, 4], "bar": 9, "barton": 7, "base": [1, 3, 4, 5, 7, 8, 9], "basi": [3, 6, 7], "basic": [3, 7], "bathythermograph": 8, "becam": 7, "becaus": [1, 4, 8, 9], "been": [2, 3, 4, 5, 6, 7, 8, 9], "befor": [3, 7], "begg": 7, "begin": 6, "behav": 9, "being": [1, 2, 4, 8], "below": [1, 4, 5, 6, 8, 9], "beneath": 8, "benefici": 7, "benefit": [3, 7], "best": [1, 2, 3, 7, 9], "best_qual": [3, 4], "better": 6, "between": [3, 4, 5, 6, 7, 8, 9], "bia": [3, 4, 6], "bias": 4, "big": 1, "bin": 4, "binari": 9, "bingham": 7, "binning_method": 4, "biologi": 9, "bit": [0, 4, 5, 9], "bitwid": 9, "bitwis": 9, "blend": [6, 8], "block": [3, 5], "blue": [0, 4], "boolean": [3, 9], "both": [4, 9], "bound": 9, "boundari": [4, 7, 8], "box": [7, 9], "br": 9, "brace": 6, "breez": 7, "briefli": 7, "bring": 4, "brought": [3, 5], "build": [1, 3, 4, 9], "built": 7, "bulk": 8, "bull": 7, "buoi": [7, 8], "byte": [0, 3, 4, 5, 9], "c": [3, 4, 5, 7], "c5dc3c903eba": 9, "calcul": [1, 3, 4], "calendar": [1, 4, 5], "calibr": [4, 6], "call": [3, 4, 5, 6, 8, 9], "can": [1, 3, 4, 5, 6, 7, 8, 9], "candid": 4, "cannot": [1, 8, 9], "capabl": 7, "capac": 7, "captur": 9, "case": [1, 3, 4, 5, 6, 8, 9], "casei": 7, "catalogu": [3, 4, 5, 6, 7, 9], "caus": 3, "cdm_data_typ": [4, 5, 9], "cdr": 9, "ce": 3, "ceil": [3, 5], "cell": [4, 5, 7], "cell_method": 4, "center": [3, 7, 9], "centr": [1, 3, 4, 5, 6, 7], "central": [2, 3, 4, 6, 7, 9], "ceo": [3, 4, 5, 6, 7, 9], "ceosresponse_1010a": 7, "cersat": [4, 5], "certain": [0, 9], "cf": [1, 4, 5, 6, 8, 9], "cfconvent": [1, 3, 9], "chain": [2, 8], "challeng": [7, 8], "chang": [1, 3, 4, 5, 7, 8, 9], "channel": [3, 9], "charact": [0, 9], "characterist": [3, 4, 5, 6, 7], "charg": [2, 4, 5], "check": 3, "chlorophyl": 3, "choos": [3, 6], "chosen": [1, 3, 6, 8, 9], "circul": 7, "circumst": 8, "citat": 5, "citi": 3, "classic": 9, "classifi": 3, "clear": [3, 5, 7, 8], "clearli": [3, 4, 6], "client": 8, "clim": 6, "climat": [2, 3, 4, 5, 6, 7, 8, 9], "climatologi": [3, 5, 6], "close": [3, 8], "closest": [3, 4, 8, 9], "cloud": [3, 7], "cmem": [4, 5, 7], "cmems_product_id": [4, 5], "coard": 9, "coastal": 3, "code": [1, 2, 4, 5, 7, 9], "codelist": 9, "coeffici": 6, "coincid": 8, "colder": 3, "collabor": 7, "collat": [1, 6, 7, 9], "collect": [2, 3, 4, 5, 6, 7], "colon": 5, "column": [0, 1, 8, 9], "com": [3, 6, 9], "combin": [1, 2, 3, 4, 5, 6, 7, 9], "come": [8, 9], "comma": [3, 4, 6, 9], "command": 9, "comment": [1, 3, 4, 9], "commerci": 7, "commit": [4, 5, 7], "committe": 7, "common": [2, 3, 4, 5, 7, 9], "commonli": 6, "commun": [2, 3, 5, 6, 7, 9], "comparison": [4, 7, 8], "compat": [4, 9], "compet": 7, "complementar": 7, "complementari": [4, 8], "complet": [1, 2, 4, 9], "complex": [7, 8], "compli": 9, "complianc": [3, 5], "compliant": [1, 3, 9], "complic": [1, 7, 8], "compon": 7, "composit": 4, "compress": 9, "comput": [0, 1, 6], "concaten": 1, "concentr": 5, "concept": [3, 8], "concern": 4, "condit": [3, 4, 7, 8, 9], "conduct": 8, "confid": [3, 4, 7], "configur": 3, "confirm": 7, "conform": [3, 6, 9], "conjunct": 6, "connect": 8, "consecut": [1, 4], "consensu": [2, 7], "consequ": [3, 8], "consid": [3, 5, 6, 7, 8, 9], "consider": [3, 8], "consist": [3, 4, 6, 7, 8, 9], "consortium": 7, "constrain": 7, "constraint": 9, "consult": 7, "contact": [4, 5, 8], "contain": [3, 4, 6, 8, 9], "contamin": [3, 5], "contemporan": [3, 4], "content": [1, 2, 6, 7, 8, 9], "context": [6, 7, 9], "continent": 9, "continu": [1, 7], "contradict": 9, "contribut": [2, 4, 9], "contributor": 4, "contributor_nam": [4, 9], "contributor_rol": [4, 9], "control": [2, 7, 9], "convect": 7, "convent": [1, 2, 3, 4, 5, 7, 8, 9], "convers": [4, 9], "convert": 9, "cool": 8, "cooper": 9, "coordin": [0, 2, 3, 4, 5, 6, 7, 8, 9], "cope": [4, 9], "copernicu": [4, 5, 7], "coral": 7, "core": [3, 4, 5, 9], "correct": [3, 4], "correl": 3, "correspond": [1, 3, 4, 6, 9], "could": [7, 8, 9], "council": 7, "count": 3, "counterpart": 4, "coupl": [3, 4, 7], "cours": 8, "cover": [3, 5, 6, 9], "coverag": [1, 3, 4, 6, 7, 9], "coverage_content_typ": [1, 3, 4, 5, 9], "coveragecontenttypecod": 9, "cr": [4, 9], "creat": [1, 3, 4, 5, 6, 7, 8, 9], "creation": [4, 6, 9], "creator": 9, "creator_email": [4, 5, 9], "creator_institut": [4, 5, 9], "creator_nam": [4, 5, 9], "creator_typ": [4, 5, 9], "creator_url": [4, 5, 9], "criteria": 6, "critic": [2, 7], "cross": [1, 4], "crss": 9, "ctd": 8, "cube": 1, "cuervo": 7, "cumul": 4, "current": [1, 6, 8, 9], "curvilinear": 1, "cycl": [7, 8], "d": [1, 3, 4, 5, 7, 9], "da": 6, "daac": [7, 9], "dac": [3, 7], "dai": [3, 4, 5, 6, 8, 9], "daili": [3, 4, 5, 7], "dash": [6, 7], "data": [0, 1, 6, 7, 8], "databas": [6, 9], "dataset": [1, 4, 6, 7, 9], "datatyp": 9, "date": 9, "date_cr": [4, 5, 9], "date_issu": [4, 5, 9], "date_metadata_modifi": [4, 5, 9], "date_modifi": [4, 5, 9], "datum": [1, 9], "dawn": [6, 8], "daytim": 8, "dd": [5, 6], "ddthh": 9, "de": [3, 4, 5, 9], "decad": 7, "decim": 9, "decis": 4, "declar": [3, 5, 9], "decompress": 9, "decreas": 1, "dedic": [3, 5], "deep": 8, "default": [1, 9], "defin": [0, 1, 4, 5, 6, 7, 8, 9], "definit": [1, 2, 3, 6, 8, 9], "degrad": 3, "degre": [1, 3, 4, 5, 9], "degree_": 4, "degree_east": [4, 9], "degree_n": 4, "degree_north": [4, 9], "degrees_east": [1, 4, 5, 9], "degrees_north": [1, 4, 5, 9], "deliv": [3, 7], "deliveri": 7, "demand": 7, "demonstr": 7, "denot": 0, "dens": 7, "depend": [1, 3, 4, 6, 8, 9], "depress": 7, "depth": [3, 6, 8, 9], "deriv": [3, 4, 5, 6, 7, 8, 9], "descend": [3, 9], "describ": [0, 1, 2, 3, 4, 5, 6, 9], "descript": [6, 7, 9], "desert": 3, "design": [7, 9], "despit": 7, "detail": [2, 3, 4, 5, 6, 7, 9], "detect": 4, "determin": [3, 4, 5, 6, 7], "develop": [2, 6, 7, 8], "deviat": [3, 4, 5, 6, 7], "diagnost": 2, "diagram": 8, "did": 7, "differ": [1, 2, 3, 4, 5, 6, 7, 8, 9], "difficult": [3, 7], "diffus": 8, "digit": [1, 6], "dimens": [0, 1, 4, 5, 9], "dimension": 9, "dimensionless": 1, "direct": [1, 8], "directli": [1, 3, 6], "directori": [4, 5, 9], "discontinu": 9, "discourag": 8, "discov": 7, "discoveri": [4, 7, 9], "discret": [3, 4, 5, 9], "discuss": [2, 7, 9], "disk": 1, "displai": 9, "distinct": [3, 6, 8], "distinguish": 6, "distribut": [4, 7, 9], "distributor": [3, 7], "diurnal": [3, 4, 8], "dn": 9, "do": [3, 4, 6, 7, 8, 9], "document": [2, 3, 4, 5, 7, 9], "doe": [3, 6, 9], "doi": [3, 4, 5, 7, 9], "domain": 6, "domin": 8, "done": [1, 4], "donlon": 7, "doubl": [0, 4, 5], "down": [3, 9], "drift": 8, "dt": [3, 9], "dt_analysi": [0, 4], "dtime": [3, 5], "due": [3, 8], "duplic": 4, "dure": [7, 8], "dust": 3, "dynam": [3, 6], "e": [1, 3, 4, 5, 6, 7, 9], "each": [1, 2, 3, 4, 5, 6, 7, 8, 9], "earlier": 6, "earth": [1, 3, 4, 7, 9], "easili": [1, 9], "east": 1, "easternmost": 9, "ecmwf": [3, 9], "ecmwf_anaylsis_v2": 3, "ecosystem": 7, "ecv": 7, "edm": 9, "edu": 9, "effect": 8, "eg": 9, "either": [1, 3, 4, 8, 9], "element": [1, 6, 9], "ellipsoid": 9, "ellp": 1, "elsewher": 9, "email": 9, "emerg": 7, "emeri": 7, "emmanuel": [4, 5], "emploi": 6, "en": 9, "enabl": 7, "encapsul": 8, "encod": [1, 3, 9], "encount": [4, 9], "encourag": [1, 6, 7, 8], "end": [7, 9], "energi": [7, 8], "enough": 6, "ensembl": [2, 6], "ensur": [6, 8], "enter": [3, 6, 7, 9], "enterpris": 7, "entir": [4, 9], "entiti": [7, 9], "entri": 6, "enum": [3, 4], "environment": [3, 7], "eo": 9, "eohandbook": [6, 9], "epsg": [4, 5, 9], "equal": [3, 4, 9], "equival": [8, 9], "era": 7, "erreur": 9, "error": [3, 4, 5, 7, 9], "erupt": 3, "esa": 3, "esdi": 9, "esipf": 9, "especi": [3, 6, 8], "essenti": [4, 7], "establish": [4, 7], "estim": [2, 3, 4, 5, 6, 7, 8], "et": [4, 5], "etc": [3, 5], "eu": [4, 5], "eumetsat": [3, 5, 7], "europ": 7, "european": 3, "evalu": 4, "evan": 7, "even": [3, 4, 8, 9], "event": 6, "eventu": 5, "everi": [4, 5, 7, 9], "evolut": 7, "evolv": 7, "exact": 9, "exampl": [0, 7, 8, 9], "excel": 9, "except": [3, 5, 9], "exchang": 7, "exet": 3, "exist": [3, 6, 9], "expect": [0, 3, 8], "expend": 8, "experi": 7, "experiment": [4, 6, 9], "experimental_field": 0, "expert": 7, "explicitli": [1, 6, 9], "exploit": [4, 5, 7], "express": [3, 9], "extend": [3, 5, 6, 9], "extens": 6, "extent": [6, 9], "extract": 1, "extrem": 9, "f": [1, 4], "facil": 7, "facilit": [0, 1, 3], "facto": 9, "factor": [1, 9], "fall": 5, "fals": 9, "false_east": [1, 9], "false_north": 1, "far": 3, "featur": 9, "featuretyp": 9, "feder": 7, "feed": 4, "ferret": 9, "few": [7, 8, 9], "field": [3, 4, 5, 9], "fig": [4, 6], "figur": [6, 7, 8], "file": [1, 2, 3, 5, 6, 7], "file_quality_level": [4, 5, 9], "filenam": 2, "fill": [3, 4, 6, 7, 9], "filter": 6, "final": [4, 7], "find": 4, "fine": 2, "finer": [4, 7], "first": [2, 3, 4, 6, 7, 9], "fisheri": 7, "five": 7, "fix": [1, 8, 9], "flag": [3, 4, 5, 6, 9], "flag_mask": [3, 5, 9], "flag_mean": [3, 4, 5, 6, 9], "flag_valu": [3, 4, 6, 9], "flexibl": [3, 5, 6, 9], "flight": [3, 9], "float": [0, 1, 4, 5, 9], "flow": 7, "flux": [7, 8], "focu": 7, "focus": 7, "follow": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], "forecast": [2, 3, 4, 5, 6, 7, 8, 9], "form": [3, 4, 5, 6, 7, 8, 9], "formal": 9, "format": [2, 6, 7], "format_vers": [4, 5], "found": 6, "foundat": [4, 5, 6, 7, 8], "four": [6, 7], "fr": [4, 5], "fraction": [1, 3, 4, 5, 6], "framework": [0, 2, 3, 5, 7, 8, 9], "franc": [4, 5], "francai": [4, 5], "francoi": 4, "free": [2, 4, 5, 6, 9], "freeli": 9, "frequenc": [6, 8], "frequent": 9, "fresh": 7, "friendli": 1, "from": [1, 2, 3, 5, 6, 7, 8], "fuel": 7, "full": [3, 5, 6, 7], "fulli": [2, 3, 5], "function": [3, 4, 7], "fund": [4, 5, 7], "fundament": [6, 7], "further": [7, 8, 9], "furthermor": 3, "furthest": 9, "futur": [3, 7], "fv": 6, "fv01": [4, 6], "g": [1, 3, 4, 5, 6, 7, 9], "ga": 7, "gal": 6, "galapago": 6, "gap": [4, 5, 6, 7], "gather": 4, "gcmd": [4, 5, 9], "gco": 7, "gcom": [4, 5], "gd": [1, 3, 4, 5], "gdac": [6, 7], "gdp": 7, "gds2": 9, "gds_version_id": [0, 4, 5, 9], "gener": [1, 2, 3, 4, 5, 6, 7, 8, 9], "gentemann": 7, "geo": [1, 3, 4, 5, 6], "geograph": [4, 5, 6, 7], "geographic_crs_nam": 1, "geoloc": [1, 9], "geometr": 6, "geometri": [3, 8, 9], "geonetwork": 9, "geophys": [6, 7, 9], "geospati": [1, 9], "geospatial_bound": [4, 5, 9], "geospatial_bounds_cr": [4, 5, 9], "geospatial_bounds_vertical_cr": [4, 5, 9], "geospatial_lat_max": [4, 5, 9], "geospatial_lat_min": [4, 5, 9], "geospatial_lat_resolut": [4, 5, 9], "geospatial_lat_unit": [4, 5, 9], "geospatial_lon_max": [4, 5, 9], "geospatial_lon_min": [4, 5, 9], "geospatial_lon_resolut": [4, 5, 9], "geospatial_lon_unit": [4, 5, 9], "geospatial_vertical_max": [4, 5, 9], "geospatial_vertical_min": [4, 5, 9], "geospatial_vertical_posit": 9, "geospatial_vertical_resolut": 9, "geospatial_vertical_unit": 9, "geostationari": [1, 3, 4, 5, 6, 9], "ghrsst": [0, 1, 8, 9], "ghv20": 3, "gigahertz": [6, 8], "github": 1, "give": [1, 3, 4, 9], "given": [1, 3, 4, 6, 8, 9], "glanc": 6, "glo_010": 4, "glob": 6, "glob_002": 5, "glob_010": 4, "global": [2, 3, 4, 5, 6, 7], "gmpe": [3, 6, 7, 9], "gmpe_glob": 3, "go": 4, "goda": 7, "goddard": 9, "goe": [4, 5, 9], "goes16": [4, 5], "goes_": 3, "goes_w": 3, "good": [3, 4], "gov": [3, 9], "govern": 4, "gradient": 3, "granul": [1, 3, 4, 6, 7, 9], "greater": 9, "green": 0, "greenwich": 1, "gregorian": 1, "grei": 0, "grid": [0, 3, 5, 6, 7, 9], "grid_map": [1, 9], "grid_mapping_nam": [1, 4], "gross": 3, "group": [2, 3, 4, 5, 6, 7, 9], "grow": 7, "growth": [7, 8], "gsa": 2, "gsfc": 9, "gt": [0, 2, 3, 5, 7, 9], "guarante": 9, "guid": 9, "guidanc": [2, 3, 5, 7, 9], "guidelin": [3, 9], "gyre": 7, "h": [3, 4, 7], "ha": [1, 2, 3, 4, 5, 6, 7, 8, 9], "handl": [7, 9], "harri": 7, "have": [1, 2, 3, 4, 6, 7, 8, 9], "health": 7, "heat": [7, 8], "height": [3, 9], "heinz": 7, "held": 7, "help": [3, 7], "henc": [4, 9], "here": 9, "heterogen": 4, "hh": 6, "hhmmss": 6, "hierarchi": 4, "high": [1, 2, 3, 4, 5, 7, 8, 9], "higher": [3, 5, 6, 7], "highest": 4, "himawari": [4, 5], "histor": 8, "histori": [4, 5, 9], "hold": [3, 9], "hole": 4, "homogen": 4, "horizont": [8, 9], "horizontal_datum_nam": 1, "host": 7, "hour": [3, 4, 5, 6, 7, 9], "hourli": [4, 5], "how": [2, 3, 5, 7], "howev": [3, 4, 7, 8, 9], "hr": 4, "html": [1, 3, 4, 9], "http": [1, 2, 3, 4, 5, 6, 7, 9], "hull": 8, "human": 9, "hurrican": 7, "hydrograph": 8, "hydrolog": 7, "hypothet": 8, "i": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], "ic": [3, 4, 5, 6, 7, 8, 9], "id": [4, 5, 6, 9], "ideal": [3, 5, 7], "ident": [3, 4, 9], "identifi": [1, 2, 5, 6, 9], "ifr": [4, 5], "ifrem": [4, 5], "illustr": 4, "imag": [1, 9], "impact": 7, "implement": [0, 1, 2, 3, 5, 7], "impli": [1, 9], "implicitli": 8, "import": [3, 6, 8], "imposs": 3, "improv": [6, 7], "includ": [1, 2, 4, 6, 7, 8, 9], "inclus": [3, 5], "incorpor": 9, "increas": [1, 3, 5, 6], "increment": 3, "independ": [7, 9], "index": 7, "indic": [3, 4, 5, 8, 9], "individu": [3, 4, 9], "influenc": 8, "inform": [1, 2, 3, 4, 5, 6, 7, 8, 9], "infrar": [3, 4, 6, 8, 9], "ingest": 7, "initi": [7, 9], "input": [2, 3, 4, 6, 7, 9], "insensit": 9, "insert": 3, "instanc": [1, 4], "instant": 3, "instantan": 9, "instead": [1, 3, 6, 8, 9], "institut": [4, 5, 7, 9], "institution_abbrevi": [4, 5], "instruct": 7, "instrument": [1, 3, 4, 5, 6, 7, 8, 9], "instrument_typ": [4, 5], "instrument_vocabulari": [4, 5, 9], "instrumentt": [6, 9], "insuffici": [6, 7], "int": [0, 1, 3, 4, 7], "int64": [1, 4], "integ": [0, 9], "integr": [2, 3, 7], "intend": [1, 4, 6], "inter": 7, "interact": [7, 8], "intercept": 9, "interdepend": 9, "interest": 1, "interfac": [3, 7, 8], "intern": [0, 2, 7, 9], "internation": 7, "internet": 9, "interoper": [7, 9], "interpol": [3, 4, 5, 6, 7], "interpret": [3, 5, 9], "interv": [4, 5], "introduc": [4, 8], "invalid": 3, "invari": 8, "inverse_flatten": [1, 4, 9], "investig": 4, "invoc": 9, "io": 1, "ir": 9, "irradi": [3, 4, 6, 8], "island": 6, "iso": [4, 5, 6, 9], "iso19115": 9, "isol": 3, "issu": [3, 5, 7, 9], "item": 0, "iter": 8, "its": [1, 3, 4, 6, 7, 9], "itself": [6, 7, 9], "j": [7, 9], "jan": 5, "januari": [1, 3], "jaxa": 7, "jean": 4, "jet": [7, 9], "jfpioll": [4, 5], "jone": 7, "jpl": 9, "jpss": 9, "julian": 1, "just": 9, "k": [1, 3, 4, 5, 7, 9], "k2": 4, "kawamura": 7, "keep": [4, 6], "kei": [3, 6, 7, 9], "kelvin": [3, 4, 5], "keyword": [4, 5, 9], "keywords_vocabulari": [4, 5, 9], "kind": [1, 4, 6], "kingdom": 3, "km": [3, 4, 7], "knowledg": [7, 8], "known": [3, 4, 6, 8, 9], "l": [4, 5, 9], "l0": 6, "l1a": 6, "l1b": 6, "l2": [2, 3, 4, 6, 7], "l2_ghrsst": 6, "l2p": [1, 2, 5, 6, 7, 9], "l2p_flag": [4, 9], "l2p_ghrsst": 6, "l2paux": 3, "l2pcore": 3, "l3": [1, 2, 6, 7, 9], "l3_ghrsst": 6, "l3c": [1, 4, 5, 6, 7, 9], "l3c_ghrsst": 6, "l3s_ghrsst": 4, "l3u": [1, 6, 7, 9], "l4": [1, 2, 3, 4, 6, 7, 8, 9], "l4_": 3, "l4_full_exampl": 5, "l4_ghrsst": 6, "la": [4, 5, 9], "label": 4, "laboratori": [7, 9], "lac": 6, "lack": 8, "laea": 1, "lake": [3, 5, 9], "lambert_azimuthal_equal_area": 1, "lambert_azimuthal_grid": 1, "laminar": 8, "land": [3, 5, 7, 9], "larg": [3, 7, 8], "larger": [1, 4, 9], "last": [7, 9], "lat": [0, 3, 4, 5, 9], "lat_0": 1, "later": [1, 3, 5, 6, 9], "latitud": [3, 4, 5, 6, 7, 9], "latitude_longitud": 4, "latitude_of_projection_origin": 1, "latter": 4, "launch": 9, "layer": [3, 8], "lead": [3, 6], "leap": 6, "least": [7, 9], "least_significant_digit": 1, "leborgn": 7, "length": 6, "less": [1, 3, 6, 7], "level": [1, 2, 7, 8, 9], "li": 4, "liber": 0, "librari": 9, "licenc": [4, 5], "licens": [4, 5, 9], "life": 7, "like": [1, 6, 7, 9], "limit": [3, 4, 5, 6, 7, 9], "line": [1, 3, 4, 5, 6, 9], "lineag": 9, "link": [3, 5, 9], "list": [4, 5, 6, 9], "llewellyn": 7, "local": [3, 4, 7, 8, 9], "locat": [1, 3, 4, 5, 6, 7, 9], "lon": [3, 4, 5, 9], "lon_0": 1, "long": [0, 7, 9], "long_nam": [1, 3, 4, 5, 9], "longitud": [4, 5, 6, 9], "longitude_of_prime_meridian": 4, "longitude_of_projection_origin": 1, "look": 3, "low": [1, 3, 8], "low_qual": [3, 4], "lower": [3, 6, 8, 9], "lowest": 7, "lstrf": 6, "ltsrf": [6, 7], "m": [3, 4, 8], "made": [3, 5, 6, 7, 8, 9], "magnitud": 3, "mai": [1, 3, 4, 5, 6, 7, 8, 9], "main": [3, 7], "maintain": [2, 3, 5, 6, 7, 9], "major": [1, 3, 6, 8, 9], "make": [1, 3, 4, 5, 6, 7], "manag": [3, 5, 7], "mandat": [6, 9], "mandatori": [0, 3, 4, 5, 6], "mani": [1, 4, 6, 8, 9], "manipul": 6, "manner": [2, 3, 4, 7, 9], "manual": [2, 4, 5, 9], "map": [1, 6, 9], "mar": [4, 5], "marin": [4, 5, 7, 9], "maritim": 7, "mask": [3, 4, 9], "master": [4, 5, 9], "match": [3, 4, 6, 9], "matter": 7, "matur": 7, "maxim": 7, "maximum": 9, "md": [5, 9], "md_coveragecontenttypecod": 9, "mean": [0, 3, 4, 8, 9], "meaning": 9, "measuement": 9, "measur": [2, 3, 4, 6, 7, 8, 9], "mechan": [2, 9], "med": 6, "median": [3, 4], "mediterranean": 6, "medium": 3, "meet": [3, 6, 7, 9], "mega": 3, "mer": [4, 5], "merchant": 7, "merg": [4, 8], "meridian": 9, "met": [3, 4, 7], "metadata": [3, 6, 7, 8, 9], "metadata_convent": 4, "metadata_link": [4, 5, 9], "meteorol": 7, "meteorolog": 7, "meteorologist": 7, "meteosat": [3, 4, 5], "meter": [6, 8, 9], "method": [3, 4, 9], "methodologi": 9, "metoffic": 3, "metop": [4, 5, 6], "metr": 3, "metric": 7, "miami": 9, "micromet": [1, 6, 8], "microwav": [3, 4, 6, 8, 9], "might": 2, "militari": 7, "millimet": 3, "millimetr": [6, 8], "min": 9, "minim": [1, 3, 5], "minimum": [3, 4, 5, 7, 8, 9], "minnett": 7, "minor": [6, 7], "minut": 6, "miscellan": 9, "misinterpret": 3, "miss": [3, 9], "mission": [4, 5, 9], "missiont": 6, "mix": [1, 3, 5, 8], "mm": [5, 6, 8, 9], "model": [3, 7, 8, 9], "modelresult": 9, "moder": 4, "modern": 7, "modif": 9, "modifi": [3, 9], "moi": 4, "moistur": 8, "molecul": 8, "momentum": [7, 8], "monitor": [3, 7], "mono": 0, "monoton": 1, "month": 6, "moor": 8, "more": [1, 3, 4, 5, 6, 7, 8, 9], "most": [1, 4, 8, 9], "mount": 8, "mrc": 9, "msg_seviri": 3, "much": 0, "multi": [2, 4, 5, 6], "multidimension": [1, 9], "multipl": [3, 6, 7, 8, 9], "multipli": [1, 9], "murrai": 7, "must": [1, 3, 4, 5, 6, 7, 8, 9], "mutlow": 7, "my": 3, "my_vari": 3, "mysit": 3, "n": [3, 6, 7], "naap": 3, "nadir": [3, 9], "name": [0, 1, 2, 4, 5, 6, 7, 8, 9], "naming_author": [4, 5, 9], "nanf": 4, "nasa": [4, 5, 7, 9], "nation": [3, 7, 9], "nativ": [1, 3, 4, 6, 7], "natur": 4, "navd88": 9, "navi": 3, "navo": [3, 6], "nc": 6, "ncei": 7, "nceo": 9, "ncep": 3, "ncml": 9, "nearest": [1, 3, 4], "necessari": [3, 4, 7, 9], "necessarili": [1, 4, 9], "need": [1, 2, 3, 4, 6, 7, 8, 9], "neg": 9, "neither": 8, "net": 8, "netcdf": [0, 1, 3, 4, 5, 6], "netcdf4": 1, "netcdf_version_id": [4, 5, 9], "network": 7, "new": [2, 3, 4, 5, 6, 7, 9], "next": 7, "ni": [0, 1, 3], "night": [8, 9], "nightingal": 7, "nj": [0, 1, 3], "nn": 6, "no_data": [3, 4], "noaa": [3, 4, 5, 6, 7, 9], "nocturn": 8, "node": [7, 9], "nomenclatur": [0, 6], "nomin": [1, 6], "non": [2, 3, 6, 9], "none": [3, 5, 6, 9], "nonregular_grid": 1, "nonregular_grid_project": 1, "nonregular_grid_projection_no_latlon": 1, "nop": 7, "nor": 8, "normal": [0, 4], "north": [1, 3], "northernmost": 9, "notat": [0, 9], "note": [3, 4, 5, 6, 8, 9], "notethat": 6, "nov": 4, "now": [3, 7, 9], "npp": [4, 5, 9], "nsidc": 3, "nug": 9, "null": 9, "number": [3, 4, 5, 6, 7, 9], "number_of_observ": 4, "numer": [4, 7, 9], "nwp": 7, "o": [3, 5, 7], "object": [4, 9], "obp": 9, "obpg": 9, "observ": [2, 3, 4, 5, 6, 7, 8, 9], "obtain": [3, 8], "occas": 8, "occasion": 9, "occur": 7, "ocean": [2, 3, 4, 5, 7, 8, 9], "oceanograph": 9, "oceanographi": [7, 9], "odyssea": [4, 5, 6], "offer": [3, 9], "offic": [3, 7, 9], "offici": 6, "offlin": 2, "offset": [1, 3, 9], "often": [4, 6, 9], "ogc": 9, "oi": 5, "onboard": 3, "onc": [5, 8], "one": [1, 3, 4, 6, 7, 8, 9], "ones": 9, "onli": [0, 1, 3, 4, 5, 6, 7, 8, 9], "onlin": 7, "onto": 4, "open": 9, "openli": 9, "opensourc": 9, "oper": [2, 3, 6, 7, 8, 9], "operation": 7, "opinion": 2, "optic": 3, "optim": [1, 2, 5, 6], "optimum": 3, "option": [0, 4], "or_number_pixel": 4, "orbit": [1, 3, 4, 6, 7, 9], "order": [1, 3, 4, 6, 9], "ordin": 1, "org": [1, 2, 3, 4, 5, 6, 7, 9], "organ": 9, "organiz": 7, "orient": 9, "origin": [1, 3, 4, 5, 6, 9], "orthogon": [1, 3], "osi": [3, 5], "osisaf": [3, 4, 5], "ostia": [3, 6], "other": [1, 2, 3, 4, 5, 6, 7, 8, 9], "otherwis": [6, 7, 9], "out": 4, "outbreak": 3, "outflow": 3, "outlier": 3, "output": [3, 4, 7, 8, 9], "outsid": 9, "over": [1, 3, 4, 5, 7, 8], "overal": [1, 3, 4, 5, 7], "overarch": 9, "overlap": [4, 6, 7], "overridden": 9, "oversatur": 3, "overview": [2, 8], "own": [0, 1, 3, 6, 7, 9], "p": [4, 7], "p1d": [4, 5], "pack": [1, 9], "packag": 9, "page": 7, "paper": 9, "paradigm": 7, "paragraph": 9, "paramet": [1, 6, 8, 9], "parnership": 9, "part": [3, 4, 5, 6, 7, 8, 9], "particip": 7, "particular": [3, 8], "particularli": 6, "pass": [3, 7], "passiv": 3, "patmo": 9, "pattern": [1, 7], "payload": 6, "pdf": [4, 5, 7], "per": [3, 4, 5, 9], "perform": [3, 7, 9], "period": [3, 4, 5, 7, 9], "permit": [1, 3, 4, 5], "persist": 9, "person": 9, "perspective_point_height": 1, "phase": 7, "phenomena": 7, "php": 7, "phrase": 9, "physic": [7, 8, 9], "physicalmeasur": [1, 3, 4, 5, 9], "pilot": 7, "pink": 0, "pioll": 4, "pioll\u00e9": 7, "pixel": [1, 3, 4, 5, 6, 9], "place": [3, 4, 5, 6, 9], "plai": 7, "plan": 7, "platform": [3, 5, 6, 7, 9], "platform_typ": [4, 5], "platform_vocabulari": [4, 5], "platform_zenith_angl": 4, "pleas": [4, 9], "plot": 9, "plouzan": [4, 5], "plu": [1, 3, 4, 9], "pmel": 9, "po": [7, 9], "podaac": 9, "point": [0, 2, 4, 7, 9], "polar": [1, 3, 4, 9], "polar_orbit": [4, 5], "polici": [4, 5], "polygon": [4, 5, 9], "portal": [2, 7], "portfolio": [4, 5, 9], "posit": 9, "possibl": [0, 3, 4, 6, 7, 8], "possibli": 9, "potenti": [3, 4, 7, 8], "poulter": 7, "pour": [4, 5], "pp": [3, 7], "practic": [1, 2, 3, 7, 8, 9], "pre": [2, 6, 7, 8], "preced": 6, "precis": [1, 3, 4, 6, 8], "predict": [3, 7], "prefer": [1, 3], "preferenti": 9, "prefix": 9, "preliminari": 4, "present": [3, 4, 5, 6, 7, 8, 9], "preserv": [4, 9], "pressur": 9, "presum": 9, "previou": [1, 3, 4], "previous": [3, 5], "primari": 6, "primarili": [6, 9], "prime": 9, "prime_meridian_nam": 1, "princip": [4, 9], "principl": [3, 4, 7], "prior": [3, 7], "priori": 4, "priorit": 4, "problem": 9, "procedur": [3, 4, 5, 6, 7, 8], "process": [1, 2, 4, 7, 8, 9], "processing_level": [4, 5, 9], "processing_softwar": [4, 5], "processor": 5, "procur": 3, "produc": [1, 2, 3, 4, 5, 6, 7, 9], "product": [0, 1, 2, 7, 8], "product_vers": [4, 5, 9], "profil": 8, "prog": 7, "program": [4, 5, 9], "programmat": 7, "proj": 1, "proj4_str": 1, "project": [0, 4, 5, 6, 7, 9], "projection_x_coordin": 1, "projection_y_coordin": 1, "proleptic_gregorian": [1, 4, 5], "prone": 3, "properli": [3, 9], "propos": 7, "proprerli": 6, "propuls": [7, 9], "prospect": 7, "protocol": [7, 9], "provid": [1, 2, 4, 6, 7, 8, 9], "provis": 9, "proviso": 3, "public": 7, "publish": 9, "publisher_email": [4, 9], "publisher_institut": [4, 5, 9], "publisher_nam": [4, 5, 9], "publisher_typ": [4, 9], "publisher_url": [4, 5, 9], "pum": [4, 5], "purpos": [3, 8, 9], "purposefulli": 7, "push": 7, "python": 1, "q": 4, "qa4eo": 3, "qualifi": 8, "qualiti": [3, 4, 6, 9], "quality_level": [4, 9], "qualityinform": [3, 4, 5, 9], "quantifi": [3, 5, 7], "quantiti": [4, 8, 9], "question": [3, 4, 6], "quickli": 6, "quicklook": 9, "quit": 4, "r": [0, 2, 3, 5, 7, 9], "radian": 1, "radianc": 3, "radiomet": [3, 4, 5, 6, 8, 9], "radiometr": [6, 8], "rain": 3, "rang": [1, 3, 4, 6, 8, 9], "rare": 3, "rate": 4, "rather": [3, 8], "rayner": 7, "rd": 7, "rdac": [5, 7, 9], "re": 7, "read": [7, 8, 9], "readabl": [6, 9], "reader": 9, "real": [2, 3, 7], "realiti": 3, "reanalysi": [2, 7], "reason": [6, 9], "receiv": 7, "recent": 9, "recept": 3, "recherch": [4, 5], "recogn": 7, "recommend": [1, 3, 4, 5, 6, 9], "reconstruct": 6, "record": [1, 6, 7, 8], "recov": 9, "rectangular": 1, "redistribut": 7, "reduc": [6, 9], "reef": 7, "refer": [0, 1, 2, 4, 5, 6, 8, 9], "referenc": 6, "reference_ellipsoid_nam": 1, "referenceinform": [4, 9], "refin": 8, "reflect": 3, "reformat": [3, 9], "regard": 6, "regim": 8, "region": [2, 3, 4, 5, 6, 7, 9], "regist": 3, "registr": 9, "regul": 7, "regular": [0, 5, 9], "regular_grid": 1, "regularli": 1, "rel": [3, 7, 9], "relat": [1, 8, 9], "relationship": [3, 8, 9], "relax": 9, "relev": [3, 5, 6, 7, 9], "rema": 9, "remain": [3, 6], "remaind": 7, "remap": [6, 7], "remind": 3, "remot": [7, 8], "remov": 1, "remss": [4, 5, 6], "remss_amsre_v5": 3, "repeat": 1, "repetit": 1, "replac": [6, 8], "report": [3, 7, 8, 9], "repres": [1, 2, 3, 4, 6, 7, 8, 9], "represent": 9, "reproduc": 4, "request": [1, 3, 5], "requir": [1, 3, 4, 5, 6, 7, 8, 9], "research": [7, 9], "reserv": [3, 6], "resolut": [1, 2, 3, 4, 5, 6, 7, 9], "resolv": 6, "resourc": [4, 6, 7], "respect": [1, 4, 6, 9], "respond": 7, "respons": [5, 6, 7, 9], "rest": 9, "restrict": 9, "result": [4, 5, 6, 7, 9], "retain": 7, "retriev": [3, 6, 9], "retrospect": 2, "return": 9, "reveal": 7, "revers": 9, "revis": 7, "reynold": 7, "rigid": 6, "rigor": 7, "rise": 7, "river": [3, 5, 9], "robinson": 7, "robust": 9, "role": [7, 9], "root": 4, "rosenti": 9, "routin": [3, 5], "rsma": 9, "rule": 3, "r\u00e9f\u00e9renc": 9, "saf": [3, 5], "safeti": 7, "saharan": 3, "same": [1, 3, 6, 7, 9], "sampl": [8, 9], "satellit": [1, 2, 3, 4, 5, 6, 7, 8, 9], "satellitair": [4, 5], "satellite_zenith_angl": 4, "save": 1, "saver": 1, "scalar": 8, "scale": [1, 3, 5, 7, 8, 9], "scale_factor": [1, 3, 4, 5, 9], "scan": [1, 4], "scene": 7, "schemat": [6, 8], "scheme": [3, 4], "school": 9, "scienc": [3, 4, 5, 6, 7, 8, 9], "scientif": [2, 7, 8, 9], "scientific_support_contact": [4, 5], "scope": 4, "sdi": 3, "sdi_v2": 3, "sea": [1, 2, 3, 4, 5, 6, 7, 9], "sea_ice_area_fract": [3, 5], "sea_ice_fract": 4, "sea_ice_fraction_dtime_from_sst": 4, "sea_ice_treat": 3, "sea_surface_foundation_temperatur": [3, 4, 5, 6, 8], "sea_surface_skin_temperatur": [1, 3, 6, 8, 9], "sea_surface_subskin_temperatur": [3, 4, 6, 8], "sea_surface_temperatur": [1, 4, 6, 8], "sea_surface_temperature_stddev": 4, "sea_water_temperatur": [3, 6, 8], "search": [7, 9], "season": [5, 7], "second": [1, 3, 4, 5, 6, 7], "section": [0, 1, 3, 4, 5, 6, 7, 8, 9], "secur": [3, 5, 7], "see": [1, 2, 3, 4, 6, 9], "seen": 7, "select": [3, 4], "self": [3, 5, 9], "semi": 5, "semi_major_axi": [1, 4, 9], "semi_minor_axi": 1, "sens": [7, 8, 9], "sensor": [1, 2, 3, 5, 6, 7, 8, 9], "sensor_zenith_angl": 3, "sentenc": 9, "sentinel": [4, 5, 7], "sep": [4, 5], "separ": [2, 3, 4, 5, 6, 9], "seri": [1, 4, 5, 7], "serv": [2, 6], "servic": [0, 2, 3, 4, 5, 7, 9], "set": [1, 2, 4, 5, 6, 7, 9], "sever": [2, 3, 4, 7, 8, 9], "seviri": [3, 4, 5], "seviri_io_sst": [4, 5], "seviri_sst": [4, 5], "sfa": 9, "shall": [1, 3, 4, 5, 6], "shape": 7, "share": [2, 4, 6, 7, 9], "shelf": 9, "ship": [7, 8], "short": [0, 1, 4, 5, 7, 9], "shortnam": 9, "should": [1, 3, 4, 5, 6, 8, 9], "show": 4, "shown": [1, 3, 4, 5, 6, 7], "si": [5, 9], "sight": [3, 4], "sign": [0, 9], "signal": 8, "signific": [1, 3, 7, 9], "similar": [1, 4, 8], "similarli": 4, "simpl": 9, "simplest": 1, "simpli": [3, 6, 8], "simplifi": [3, 5, 8], "simultan": 3, "sinc": [1, 3, 4, 5, 6, 7, 9], "singl": [3, 4, 5, 6, 7, 8, 9], "situ": [2, 3, 4, 6, 7, 8], "situat": [0, 4, 6, 8], "six": [5, 7], "size": [1, 3, 4, 5, 9], "ski": 8, "skin": [1, 3, 4, 6, 7, 8, 9], "skip": 9, "sky": 3, "slab": 1, "slope": 9, "slot": 4, "slowli": 8, "slstr": [4, 5], "slstra": [4, 5], "slstrb": [4, 5], "small": 8, "smaller": [3, 4, 9], "smallest": 7, "snpp_sst": 9, "snpp_sst3": 9, "so": [3, 4, 6, 9], "soc": 7, "societ": [3, 7], "softwar": 9, "solar": [3, 4, 6, 8], "solar_zenith_angl": 4, "some": [1, 3, 4, 5, 6, 7, 8, 9], "sometim": [6, 8], "sought": 7, "sourc": [2, 4, 5, 6, 7, 8, 9], "source_data": 5, "source_of_adi": 4, "source_of_sea_ice_fract": 4, "source_of_ssi": 4, "source_of_sst": 6, "source_of_wind_spe": [4, 9], "source_of_xxx": 9, "source_vers": [4, 5], "south": 1, "southernmost": 9, "space": [1, 3, 4, 6, 7, 8, 9], "spare": [3, 5], "spatial": [2, 7], "spatial_resolut": [4, 5, 9], "spatio": 1, "special": [4, 6], "specif": [0, 1, 6, 7, 8, 9], "specifi": [1, 3, 4, 6, 8, 9], "speed": [3, 4, 6, 8, 9], "spent": [3, 5], "split": 3, "sponsor": 9, "squar": 4, "ss": [3, 4, 6], "sses_bia": 4, "sses_standard_devi": 4, "ssi": [3, 6], "ssi_dtime_fraction_dtime_from_sst": 3, "ssi_dtime_from_sst": 4, "sst": [1, 2, 8, 9], "sst1": 8, "sst5m": 6, "sst6m": 8, "sst_": 3, "sst_anomali": 5, "sst_dtime": [1, 4], "sst_glo_phy_l4_nrt_010_043": 5, "sst_glo_sst_l3s_nrt_observations_010_010": 4, "sst_s0123_e0135": 6, "sstblend": [6, 8], "sstdepth": [3, 6, 8], "sstfnd": [3, 4, 6, 8], "sstint": [3, 6, 8], "sstskin": [3, 6, 8], "sstsubskin": [3, 6, 8], "sstz": 8, "ssz": 9, "stage": 7, "stand": [1, 9], "standard": [1, 2, 4, 5, 6, 7, 8, 9], "standard_devi": 4, "standard_nam": [1, 3, 4, 5, 8, 9], "standard_name_vocabulari": [4, 5, 9], "star": [4, 5], "start": [1, 3, 6, 7, 9], "start_tim": 9, "state": [3, 7], "statement": [4, 8], "statist": [3, 4, 5, 7], "status_flag": 4, "std": 4, "step": 4, "stereograph": 1, "stewardship": 7, "still": [4, 6], "stop": [6, 9], "stop_tim": 9, "storag": [1, 3, 4, 5, 9], "store": [1, 3, 4, 7, 9], "storm": 7, "straddl": 4, "straightforward": 4, "stratif": [3, 8], "stratifi": 8, "stream": [2, 3, 7], "strength": 3, "strict": [1, 6], "strictli": [1, 7, 9], "string": [0, 4, 9], "strive": [3, 6], "stronger": 3, "strongli": 9, "structur": [2, 7, 8], "stval": 4, "sub": [0, 3, 6, 8], "subject": 8, "submit": 9, "subsidiar": 7, "subskin": [3, 4, 8], "subsurfac": 3, "subtract": 9, "success": 7, "successfulli": 7, "suffici": [3, 9], "suffix": 6, "suggest": 3, "suit": [7, 9], "suitabl": 3, "sum": [3, 4, 5], "summar": [3, 4, 5, 6, 9], "summari": [7, 9], "summaris": [7, 8], "sun": [3, 4, 7], "suomi": 9, "super": [6, 7], "suppli": [8, 9], "support": [2, 7, 9], "supposedli": 4, "surfac": [1, 2, 3, 4, 5, 6, 7, 9], "surface_downwelling_spherical_irradiance_in_sea_wat": 3, "surface_solar_irradi": 4, "surface_temperatur": 8, "surg": 7, "surrog": 3, "surround": 8, "survei": 8, "suspect": 9, "sustain": 7, "swath": [3, 4, 9], "sweep_angle_axi": 1, "synergi": 7, "synthet": 4, "system": [3, 4, 5, 6, 7, 8, 9], "systemat": 3, "t": [1, 3, 4, 5, 7, 9], "tabl": [1, 2, 3, 4, 5, 7, 9], "tag": 6, "tailor": 3, "take": [4, 8], "taken": [4, 9], "target": [4, 7, 9], "task": [2, 7], "td": 7, "team": [3, 4, 5, 6, 7, 8], "technic": [0, 2, 6, 7], "technical_support_contact": [4, 5], "techniqu": [3, 4, 6, 7, 8], "technologi": 8, "telemachu": 4, "temperatur": [1, 2, 3, 4, 5, 6, 7, 9], "tempor": [2, 7, 8], "temporal_resolut": [4, 5], "ten": 8, "term": [7, 8, 9], "terminologi": 8, "terrestri": 7, "test": [5, 7], "text": [4, 9], "textual": 9, "than": [1, 3, 4, 5, 6, 8, 9], "thei": [1, 3, 4, 5, 6, 7, 8, 9], "thematicclassif": 9, "theoret": [3, 8], "therefor": [1, 8, 9], "thermal": [3, 7, 8, 9], "thermistor": 8, "thermoclin": 8, "thermohalin": 8, "thermometri": 8, "thermosalinograph": 8, "thi": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], "thick": 8, "those": [0, 3, 6, 8, 9], "though": 3, "thought": 8, "thousand": 8, "thredd": [1, 9], "three": [4, 6], "through": [2, 3, 5, 6, 7, 8, 9], "throughout": [0, 2], "thu": 4, "time": [1, 2, 3, 4, 5, 7, 8, 9], "time_coverage_dur": 4, "time_coverage_end": [4, 5, 9], "time_coverage_resolut": [4, 5], "time_coverage_start": [4, 5, 9], "time_offset": [3, 9], "timescal": 7, "titl": [4, 5, 9], "tmi": 6, "tmi_20070503rt": 6, "todai": 7, "togeth": [3, 4, 5, 6, 8, 9], "too": [3, 6], "tool": [1, 7, 9], "top": [1, 3], "topmost": 8, "total": [3, 4, 5], "tourism": 7, "toward": 7, "traceabl": 4, "track": 1, "tradition": 8, "trail": 9, "transform": 9, "transit": 5, "transport": [2, 8], "treat": [3, 9], "tree": 4, "tropic": [3, 7], "trouv\u00e9": 9, "true": 9, "tsg": 8, "turbul": [3, 8], "two": [1, 3, 4, 6, 7], "txt": 9, "type": [1, 3, 4, 5, 7, 8, 9], "type_of_mask": 5, "typic": [6, 7, 8, 9], "u": [3, 7], "ucar": 9, "udunit": [1, 9], "uk": [3, 9], "ukmo": 6, "um": 9, "un": [4, 6], "unabl": 9, "unavail": 7, "uncertainti": [2, 3, 4, 6, 7], "uncol": 7, "under": [3, 4, 5, 6, 8, 9], "underscor": [3, 6], "understand": [2, 3, 7, 8], "understood": 9, "underwai": 8, "unfccc": 7, "unfit": 6, "unidata": [1, 9], "uniqu": [3, 4, 9], "unit": [1, 3, 4, 5, 6, 9], "unitless": [3, 4, 5], "univers": 9, "universally_unique_identifi": 9, "unknown": [6, 9], "unlimit": 1, "unmodifi": 3, "unpack": 9, "unprocess": 6, "unsign": 9, "until": 9, "up": [3, 5, 7, 9], "updat": 7, "upon": 6, "upper": [3, 5, 7, 8, 9], "uri": 9, "url": [3, 5, 9], "urn": 9, "us": [1, 2, 4, 5, 6, 7, 8, 9], "usabl": [3, 6], "use_a_cf_standard_name_if_avail": 3, "user": [1, 2, 3, 4, 5, 6, 7, 9], "usual": [1, 5, 8], "utc": [1, 3, 6], "util": 1, "uuid": [4, 5, 9], "v": 6, "v02": [4, 6], "v1": [3, 4, 5, 7, 9], "v2": [3, 4, 5], "v2016": 9, "v27": 9, "v2r5": 9, "v3": [3, 4], "v6": 3, "v79": [4, 5], "v8": [4, 5], "valid": [1, 3, 7, 8, 9], "valid_rang": [1, 4, 5, 9], "valu": [1, 3, 4, 5, 6, 8, 9], "value_rang": 9, "vari": [8, 9], "variabl": [0, 2, 7, 8], "variat": [3, 7], "varieti": [2, 3, 4, 7, 8], "variou": [2, 3, 4, 6, 7, 8, 9], "vazquez": 7, "vector": [1, 9], "ver": 5, "veri": [3, 5, 8], "version": [3, 4, 5, 6, 7], "version_mask": 5, "versionof": 9, "vertic": [6, 8, 9], "vessel": 8, "via": [7, 9], "view": 3, "viir": [3, 4, 5, 9], "viirs_n20": [4, 5], "viirs_npp": [4, 5, 9], "viirss_npp": 9, "violet": 0, "visibl": [3, 9], "vocabulari": [6, 9], "vol": 7, "volcan": 3, "volum": [1, 8, 9], "w": [3, 4, 5, 9], "wa": [6, 7, 8, 9], "wai": [3, 7], "waiver": [3, 5], "ward": 7, "warm": [4, 8], "warn": 9, "water": [5, 7, 8, 9], "wave": 7, "wavelength": [6, 8], "we": [3, 6, 9], "weak": 3, "weather": [3, 7], "web": 9, "websit": [3, 6], "weight": 4, "well": [1, 3, 4, 7, 8, 9], "were": [1, 3, 4, 6, 7], "west": 1, "westernmost": 9, "wg": 1, "wgs84": [1, 4, 5, 9], "wgs_1984": 1, "what": [8, 9], "when": [1, 3, 4, 5, 6, 7, 8, 9], "where": [1, 3, 4, 5, 6, 7, 9], "wherev": 8, "whether": 6, "which": [1, 2, 3, 4, 5, 6, 7, 8, 9], "while": [1, 3, 4, 5, 6, 7, 8, 9], "white": 9, "whitespac": 9, "who": [2, 7], "whole": 9, "wholli": [3, 5], "whose": [3, 4, 6, 8], "wick": 7, "wide": [7, 8], "wider": 9, "wiki": 9, "wikipedia": 9, "wind": [3, 4, 6, 7, 8, 9], "wind_spe": [4, 9], "wind_speed_dtime_from_sst": 4, "window": [1, 4, 6, 7], "wish": [2, 3, 8], "within": [0, 2, 3, 6, 7, 8, 9], "without": [3, 4, 6, 7, 8, 9], "wkt": 9, "wmo": 7, "word": [3, 9], "work": [5, 7], "workshop": [7, 8], "world": [3, 7], "worst": 3, "worst_qual": [3, 4], "would": [6, 7, 8, 9], "wsp": [3, 6], "www": [2, 3, 4, 6, 7, 9], "x": [1, 3, 4, 5, 6, 9], "xbt": 8, "xml": 6, "xx": 6, "y": [1, 4, 5, 6, 9], "year": [5, 6, 7], "yellow": [0, 4], "you": 9, "your": 9, "yyyi": [5, 6, 9], "yyyymmdd": 6, "z": [8, 9], "zenith": [3, 4]}, "titles": ["1. Document Conventions", "6. Coordinate variables", "The Recommended GHRSST Data Specification (GDS) Version 2.1r0", "7. Level 2 Pre-processed (L2P) Product Specification", "8. Level 3 (L3) Product Specification", "9. Level 4 (L4) Product Specification", "4. GDS Filenames and Supporting Conventions", "2. Overview of GHRSST and the GDS-2.1r0", "3. Sea Surface Temperature", "5. GDS Data Product File Structure and attributes"], "titleterms": {"1": [3, 7, 9], "1r0": [2, 7, 9], "2": [2, 3, 4, 7, 9], "3": 4, "4": 5, "7": 3, "The": [2, 7], "addit": [6, 8], "adi_dtime_from_sst": 3, "adjust": 4, "adjusted_sea_surface_temperatur": 4, "adjusted_standard_deviation_error": 4, "aerosol_dynamic_ind": 3, "altern": 1, "analysed_sst": 5, "analysis_error": 5, "ancillari": 6, "ar": 9, "arrai": 1, "attribut": 9, "best": [4, 6], "bias_to_reference_sst": 4, "bit": 3, "blue": 9, "cdl": [1, 3, 4, 5], "cf": 3, "charact": 6, "code": [3, 6], "collat": 4, "colour": 0, "comment": 5, "compon": 6, "compos": 3, "comput": 3, "content": [3, 4, 5], "convent": [0, 6], "coordin": 1, "courier": [3, 4, 5], "data": [2, 3, 4, 5, 9], "dataset": [3, 5], "date": 6, "defin": 3, "definit": 0, "deprec": 9, "descript": [3, 4, 5], "detail": 8, "document": 0, "dt_analysi": 3, "establish": 6, "exampl": [1, 3, 4, 5, 6], "experiment": [3, 5], "explicit": 1, "famili": [3, 4, 5], "file": [4, 9], "filenam": 6, "fix": 4, "font": [3, 4, 5], "form": 1, "format": [3, 4, 5, 9], "from": [4, 9], "gd": [0, 2, 6, 7, 9], "geograph": 1, "ghrsst": [2, 3, 4, 5, 6, 7], "global": 9, "grid": [1, 4], "header": 4, "histori": 7, "identifi": 3, "import": 7, "includ": [3, 5], "indic": 6, "l2p": [3, 4], "l2p_flag": 3, "l3": 4, "l4": 5, "lat": 1, "latitud": 1, "level": [3, 4, 5, 6], "list": 3, "lon": 1, "longitud": 1, "mandatori": 9, "mask": 5, "multipl": 4, "name": 3, "netcdf": 9, "non": 1, "note": 1, "numer": [3, 6], "option": [3, 5, 6, 9], "or_latitud": 4, "or_longitud": 4, "or_number_of_pixel": 4, "orang": 9, "organ": 7, "overview": [3, 4, 5, 6, 7, 9], "platform": 4, "practic": [4, 6], "pre": 3, "previou": 9, "process": [3, 6], "product": [3, 4, 5, 6, 9], "project": 1, "provid": [3, 5], "purpl": 9, "quality_level": 3, "rdac": 6, "recommend": 2, "record": [3, 4, 5], "refer": 3, "regular": 1, "remap": 4, "same": 4, "sampl": 4, "satellite_zenith_angl": 3, "sea": 8, "sea_ice_fract": [3, 5], "sea_ice_fraction_dtime_from_sst": 3, "sea_ice_fraction_error": 5, "sea_surface_temperatur": 3, "segreg": 6, "sensor": 4, "set": 3, "short": 3, "solar_zenith_angl": 3, "sourc": 3, "source_of_adi": 3, "source_of_sea_ice_fract": 3, "source_of_ssi": 3, "source_of_sst": 4, "source_of_wind_spe": 3, "span": [3, 4, 5], "spatial": 1, "specif": [2, 3, 4, 5], "sses_bia": 3, "sses_standard_devi": 3, "ssi_dtime_from_sst": 3, "sst": [3, 4, 5, 6, 7], "sst_dtime": 3, "standard": 3, "standard_deviation_to_reference_sst": 4, "storag": 0, "string": [3, 6], "structur": 9, "style": [0, 3, 4, 5], "sum_square_sst": 4, "sum_sst": 4, "summari": [3, 4, 5, 6], "super": 4, "support": 6, "surfac": 8, "surface_solar_irradi": 3, "swath": 1, "tabl": [0, 6], "temperatur": 8, "templat": 3, "tempor": 1, "text": [0, 3, 6], "time": 6, "type": [0, 6], "uniqu": 6, "us": [0, 3], "variabl": [1, 3, 4, 5, 6, 9], "version": [2, 9], "wind_spe": 3, "wind_speed_dtime_from_sst": 3, "within": [4, 5], "without": 1}})sea_surface_temperature.html0000664000175000017500000006730114744715212017053 0ustar jfpiollejfpiolle 3. Sea Surface Temperature — The Recommended GHRSST Data Specification (GDS)

Sea Surface Temperature

3. Sea Surface Temperature#

SST is a challenging parameter to define precisely as the upper ocean (~10 m) has a complex and variable vertical temperature structure that is related to ocean turbulence and air-sea fluxes of heat, moisture and momentum. A theoretical framework is therefore required to understand the information content and relationships between measurements of SST made by different satellites and in situ instruments, especially if these are to be merged together. The definitions of SST developed by the GHRSST SST Science Team (agreed at the 2nd and 3rd workshops) achieve the closest possible coincidence between what is defined and what can be measured, taking into account current scientific knowledge and understanding of the near-surface thermal structure of the ocean.

The definitions of SST defined by GHRSST are currently being refined by the Science Team. Once approved, the GHRSST SST definitions will be iterated with the Climate and Forecast (CF) metadata convention definitions of SST to ensure they are in agreement.

The figure below presents a schematic diagram that summarises the definition of SST in the upper 10 m of the ocean and provides a framework to understand the differences between complementary SST measurements. It encapsulates the effects of dominant heat transport processes and time scales of variability associated with distinct vertical and volume regimes of the upper ocean water column (horizontal and temporal variability is implicitly assumed).

_images/sst-definition.gif

Fig. 3.1 Overview of SST measurement types used within GHRSST#

CF Definition:

sea_surface_temperature is usually abbreviated as “SST”. It is the temperature of sea water near the surface (including the part under sea-ice, if any), and not the interface temperature, whose standard name is surface_temperature. For the temperature of sea water at a particular depth or layer, a data variable of sea_water_temperature with a vertical coordinate axis should be used.

Additional details

The interface temperature (SSTint) is a theoretical temperature at the precise air-sea interface. It represents the hypothetical temperature of the topmost layer of the ocean water and could be thought of as an even mix of water and air molecules. SSTint is of no practical use because it cannot be measured using current technology. It is important to note that it is the SSTint that interacts with the atmosphere. Within GHRSST, most variables containing SST are named “sea_surface_temperature” to simplify the development of client applications wishing to read these variables. The variable attribute “standard_name” indicates the precise form of the SST, using the following definitions. More detail is given in the Level 2P (Section 9), Level 3 (Section 10), and Level 4 (Section 11) specification.

Sea_surface_skin_temperature (GHRSST : SSTskin):

CF Definition:

The surface called “surface” means the lower boundary of the atmosphere. The sea surface skin temperature is the temperature measured by an infrared radiometer typically operating at wavelengths in the range 3.7 - 12 micrometers. It represents the temperature within the conductive diffusion-dominated sub-layer at a depth of approximately 10 - 20 micrometers below the air-sea interface. Measurements of this quantity are subject to a large potential diurnal cycle including cool skin layer effects (especially at night under clear skies and low wind speed conditions) and warm layer effects in the daytime.

Additional Details:

The sea surface skin temperature (SSTskin) as defined above represents the actual temperature of the water across a very small depth of approximately 20 micrometers. This definition is chosen for consistency with the majority of infrared satellite and ship mounted radiometer measurements.

Sea_surface_subskin_temperature (GHRSST : SSTsubskin):

CF Definition:

The surface called “surface” means the lower boundary of the atmosphere. The sea surface subskin temperature is the temperature at the base of the conductive laminar sub-layer of the ocean surface, that is, at a depth of approximately 1 - 1.5 millimetres below the air-sea interface. For practical purposes, this quantity can be well approximated to the measurement of surface temperature by a microwave radiometer operating in the 6 - 11 gigahertz frequency range, but the relationship is neither direct nor invariant to changing physical conditions or to the specific geometry of the microwave measurements. Measurements of this quantity are subject to a large potential diurnal cycle due to thermal stratification of the upper ocean layer in low wind speed high solar irradiance conditions.

Additional Details:

The sea surface subskin temperature (SSTsubskin) represents the temperature at the base of the thermal skin layer. The difference between SSTint and SSTsubskin is related to the net flux of heat through the thermal skin layer. SSTsubskin is the temperature of a layer approximately 1 mm thick at the ocean surface.

Sea_water_temperature (GHRSST : SSTdepth or SSTz):

CF Definition:

The general term, “bulk” sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable.

Additional Details:

Sea water temperature (SSTdepth or SSTz, for example SST1.5m) is the terminology adopted by GHRSST to represent in situ measurements near the surface of the ocean that have traditionally been reported simply as SST or “bulk” SST. For example SST6m would refer to an SST measurement made at a depth of 6 m. Without a clear statement of the precise depth at which the SST measurement was made, and the circumstances surrounding the measurement, such a sample lacks the information needed for comparison with, or validation of satellite-derived estimates of SST using other data sources. The terminology has been introduced to encourage the reporting of depth (z) along with the temperature.

All measurements of water temperature beneath the SSTsubskin are obtained from a wide variety of sensors such as drifting buoys having single temperature sensors attached to their hull, moored buoys that sometimes include deep thermistor chains at depths ranging from a few meters to a few thousand meters, thermosalinograph (TSG) systems aboard ships recording at a fixed depth while the vessel is underway, Conductivity Temperature and Depth (CTD) systems providing detailed vertical profiles of the thermohaline structure used during hydrographic surveys and to considerable depths of several thousand meters, and various expendable bathythermograph systems (XBT). In all cases, these temperature observations are distinct from those obtained using remote sensing techniques and measurements at a given depth should be referred to as sea_water_temperature qualified by a depth in meters rather than sea surface temperatures. The situation is complicated further when one considers ocean model outputs for which the SST may be the mean SST over a layer of the ocean several tens of meters thick.

Sea_surface_foundation_temperature (GHRSST : SSTfnd):

CF Definition:

The surface called “surface” means the lower boundary of the atmosphere. The sea surface foundation temperature is the water temperature that is not influenced by a thermally stratified layer of diurnal temperature variability (either by daytime warming or nocturnal cooling). The foundation temperature is named to indicate that it is the temperature from which the growth of the diurnal thermocline develops each day, noting that on some occasions with a deep mixed layer there is no clear foundation temperature in the surface layer. In general, sea surface foundation temperature will be similar to a night-time minimum or pre-dawn value at depths of between approximately 1 and 5 meters. In the absence of any diurnal signal, the foundation temperature is considered equivalent to the quantity with standard name sea_surface_subskin_temperature. The sea surface foundation temperature defines a level in the upper water column that varies in depth, space, and time depending on the local balance between thermal stratification and turbulent energy and is expected to change slowly over the course of a day. If possible, a data variable with the standard name sea_surface_foundation_temperature should be used with a scalar vertical coordinate variable to specify the depth of the foundation level. Sea surface foundation temperature is measured at the base of the diurnal thermocline or as close to the water surface as possible in the absence of thermal stratification. Only in situ contact thermometry is able to measure the sea surface foundation temperature. Analysis procedures must be used to estimate sea surface foundation temperature value from radiometric satellite measurements of the quantities with standard names sea_surface_skin_temperature and sea_surface_subskin_temperature. Sea surface foundation temperature provides a connection with the historical concept of a “bulk” sea surface temperature considered representative of the oceanic mixed layer temperature that is typically represented by any sea temperature measurement within the upper ocean over a depth range of 1 to approximately 20 meters. The general term, “bulk” sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. Sea surface foundation temperature provides a more precise, well-defined quantity than “bulk” sea surface temperature and, consequently, is more representative of the mixed layer temperature. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable.

Additional Details:

Through the definition of the CF standard names, GHRSST is attempting to discourage the use of the term “bulk SST”, replacing it instead with sea_water_temperature (SSTdepth) and a depth coordinate, or sea_surface_foundation_temperature (SSTfnd) and a depth coordinate if possible, if the observation comes from the base of the diurnal thermocline.

Blended SST (GHRSST : SSTblend): In addition to the CF standard names defined above, GHRSST also uses the term “Blended SST” for ambiguous cases when the depth or type of SST is not well known. This ambiguity in depth may arise in some L4 analysis products that merge multiple types of SST from satellite and in situ observations. Note, however, that many L4 analysis systems do attempt to specifically create a sea surface foundation temperature, SSTfnd.

_sources/0000775000175000017500000000000014744715212013103 5ustar jfpiollejfpiolle_sources/overview.md0000664000175000017500000005302014705500531015264 0ustar jfpiollejfpiolle# Overview of GHRSST and the GDS-{{gds_version}} **GHRSST** [^footnote0] is an international consortium representing commercial enterprises, academic institutions, research organizations, and operational agencies that collaborate to provide accurate, high resolution, and consistently formatted SST observations and analyses from space-based platforms. This section briefly provides information on the importance of SST, an overview and history of GHRSST, and context for understanding the **GDS-{{gds_version}}**. ## The Importance of SST Sea Surface Temperature at the ocean-atmosphere interface is a fundamental variable for understanding, monitoring, and predicting fluxes of heat, momentum, and gas at a variety of scales that determine complex interactions between atmosphere and ocean. The ocean stores heat from the sun and redistributes it from the tropical regions to higher latitudes and to the less dense atmosphere regulating global weather and climate. Through the hydrological cycle the coupled system controls terrestrial life by redistributing fresh water over the land surface. From large ocean gyres and atmospheric circulation cells that fuel atmospheric depression systems, storms and hurricanes with their attendant wind waves and storm surges, to local scale phenomena such as the generation of sea breezes and convection clouds, SST at the ocean-atmosphere interface has a significant societal impact. Accurate knowledge of global SST distribution and temporal variation at finer spatial resolution is needed as a key input to numerical weather prediction (NWP) and numerical ocean prediction (NOP) systems to constrain the modelled upper-ocean circulation and thermal structure at daily, seasonal, decadal, and climatic time scales, for the exchange of energy between the ocean and atmosphere in coupled ocean-atmosphere models, and as boundary conditions for ocean forecasting models. Such models are widely used operationally for various applications including maritime safety, military operations, ecosystem assessments, fisheries support, and tourism. In addition, well-defined and quantified error estimates of SST are also required for climate time series that can be analysed to reveal the role of the ocean in short and long term climate variability. A 30 year record of satellite SST observations is available now, that grows on a daily basis. SST climate data records that are used to provide the GCOS SST Essential Climate Variable (ECV) [^footnote1], [^footnote2], [^footnote3] are essential to monitoring and understanding climate variability, climate-ecosystem interactions such as coral reef health and sustainable fisheries management, and critical issues like sea level rise and changing sea ice patterns. ## GHRSST History In 1998, SST data production was considered a mature component of the observing system with demonstrated capability and data products. However, SST product availability was limited to a few data sets that were large, scientific in format and difficult to exchange in a near real time manner. Product accuracy was considered insufficient for the emerging NWP and NOP systems. Uncertainty estimates for SST products were unavailable with SST products complicating their application by the NWP and NOP data assimilation community. At the same time the number of applications requiring an accurate high resolution SST data stream was growing. Considering these issues, the Global Ocean Data Assimilation Experiment (GODAE) [[^footnote4]] defined the minimum data specification required for use in operational ocean models, stating that SST observations with global coverage, a spatial resolution of 10 km and an accuracy of <0.4 K need to be updated every six hours [[^footnote4]]. Despite the network of SST observations from ships and buoys, the only way to achieve these demanding specifications was to make full use of space-based observations. An integrated and international approach was sought to improve satellite SST measurements, based on four principles: - Respond to user SST requirements through a consensus approach, - Organize activities according to principles of shared responsibility and subsidiarity, handling matters with the lowest, smallest, or least centralized competent group possible, - Develop complementarities between independent measurements from earth observation satellites and in situ sensors, - Maximize synergy benefits of an integrated SST measurement system and end-to-end user service. These foundations enabled the international ocean remote sensing community, marine meteorologists, Space Agencies, and ocean modellers to combine their energies to meet the GODAE requirements by establishing the GODAE High Resolution Sea Surface Temperature Pilot Project (GHRSST-PP). GHRSST-PP established four main tasks relevant to the development of the SST observing system: - Improve SST data assembly/delivery, - Test available SST data sources, - Perform inter-comparison of SST products, - Develop applications and data assimilation of SST to demonstrate the benefit of the improved observing system. GHRSST-PP successfully demonstrated that the requirements of GODAE could be met when significant amounts of GHRSST-PP data became available in 2006 and was instrumental in defining the shape and form of the modern-era SST measurement system and user service over the last 10 years [^footnote0]. At the end of the GODAE period in 2009, the GHRSST-PP evolved into the Group for High Resolution SST (GHRSST). GHRSST built on the successes of the pilot project phase and continued a series of international workshops that were held during 2000-2009. These workshops established a set of user requirements for all GHRSST activities in five areas: - Scientific development and applications, - Operational agency requirements, - SST product specifications, - Programmatic organization of an international SST service, - Developing scientific techniques to improve products and exploit the observing system. These requirements were critical to establishing the GHRSST framework and work plan and formed an essential part of the GHRSST evolution. By establishing and documenting clear requirements in a consultative manner at the start of the project and through all stages of its development, GHRSST was able to develop confidently and purposefully to address the needs of the international SST user community. ## GHRSST Organization Over the last two decades, GHRSST established and now continues to provide an internationally distributed suite of user focused services in a sustained Regional/Global Task Sharing (R/GTS) framework [AD-11] that addresses international organizational challenges and recognizes the implementing institutional capacities, capabilities, and funding prospects. Long term stewardship, user support and help services, and standards-based data management and interoperability have been developed and are operated within the R/GTS on a daily basis. The first GHRSST Level 2P datasets were made available in 2006. Since then the GHRSST R/G TS framework did not change up to 2019. Datasets produced from the collection of international 14 Regional Data Assembly Centres (RDACs) were ingested by a Global Data Assembly Centre (GDAC), such as the US GDAC located at the NASA Jet Propulsion Laboratory, Physical Oceanography Active Archive Data Center PO.DAAC). These data were made available for public distribution via a number of access protocols, tools and services, and also staged for ingestion. Final archiving and further distribution services were performed by the Long-term Stewardship and Reanalysis Facility (LTSRF) located at the NOAA National Center for Environmental Information (NCEI). This initial GHRSST R/G TS Framework is presented in Figure 6-1. Although this initial paradigm has functioned well, it has deviated from its initial design with the growing number of producers and datasets. As seen in the dashed box in Figure, a new GDAC was set-up in Europe, delivering products not available at the US GDAC, while other producers (e.g. CMEMS, Copernicus/EUMETSAT, and JAXA) are also now delivering products through their own services without any push to a GDAC. It was recognized by the GHRSST data management experts, through discussions from 2017 to 2019, and confirmed at the annual GHRSST science team meetings, that a more defined sharing of data management resources would be beneficial to the future growth of GHRSST and encourage more participation by other potential data producers. The specification of the GHRSST data management paradigm for the next years is the focus of the next sections. It can be summarised by a more distributed system where no entity, but the GHRSST Project Office, plays a central role anymore, as shown on Figure 6-2. In the new R/G TS framework, there are now only two types of entities: data producers (GDP or GHRSST Data Producers) and distributing centres (DAC or Data Assembly Centre). The two roles can be combined by a single institution (for example, EUMETSAT which produces and delivers Sentinel-3 A & B products). The GHRSST Project Office (GHRSST-PO) provides and maintains on its portal a central catalogue of all GHRSST datasets providing collection (dataset) level metadata, and federated search and discovery services. Each DAC must implement a minimum set of services for granule data access, search and discovery, production/distribution metrics and long-term archiving. Figure 6-2: Revised architecture proposal. Multiple interfaces are now available to data producers. Each data node implements interface, distribution, archiving and metadata services for the datasets they are responsible for. Data and metadata from data producers (GDPs) flow first to a DAC (like PO.DAAC, before as the US GDAC). There is no more GDAC with the commitment to host all GHRSST datasets, it is now a shared task between DACs and some datasets can be distributed by several DACs. The GHRSST-PO portal allows the user to discover and search all GHRSST products and granules without prior knowledge of who is the producer or distributor. Each component of the R/GTS is independently managed and operated by different institutions and agencies. The R/GTS itself is coordinated by the international GHRSST Science Team, which receives guidance and advice from the GHRSST Advisory Council. A GHRSST Project Office coordinates the overall framework. ## Overview of the GDS-2.1 The GHRSST R/GTS was made possible through the establishment of a rigorous GHRSST Technical Data Specification (GDS), which instructed international satellite data providers on how to process satellite data streams, defined the format and content of the data and metadata, and documented the basic approaches to providing uncertainty estimates and auxiliary data sets. The GHRSST-PP established the first GDS (v1.6) [RD-1], which formed the basis of all GHRSST data production from 2005 through today. Since 2010 the Version 2 of the GDS has been used in operations, with minor updates occurring from time to time. All GHRSST products entering the R/GTS must strictly follow the common GDS when generating L2P, L3, L4, and GMPE data. As a result, users with common tools to read data from one RDAC can securely use data from any of the others as well as the GDAC and LTSRF without a need to re-code. Table 6-1 provides a summary of GDS-2.1 data products and their basic characteristics. The remainder of this document provides the detailed specifications for GHRSST L2P, L3, L4, and GMPE products, their file naming convention, metadata requirements, and all necessary tables, conventions, and best practices for creating and using GHRSST data. | SST Product | L2 Pre-Processed {numref}`l2p` | L3 Uncollated [Section 1010] | L3 Collated[Section 10] | L3 Super-collated[Section 10] | Analyzed SST[Section 11] | |:--------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Acronym | L2P | L3U | L3C | L3S | L4 | | Description | Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates. No adjustments to input SST have been made. | L2 data granules remapped to a space grid without combining any observations from overlapping orbits. | SST measurements combined from a single instrument into a space-time grid. | Multiple passes/scenes of data can be combined. Adjustments may be made to input SST data. | SST measurements combined from multiple instruments into a space-time grid. Multiple passes/scenes of data are combined. Adjustments may be made to input SST data. | Data sets created from the analysis of lower level data that results in gridded, gap-free products. SST data generated from multiple sources of satellite data using optimal interpolation are an example of L4 GHRSST products | | Grid specification | Native to SST data format | Defined by data provider | Defined by data provider | Defined by data provider | Defined by data provider | | Temporal resolution | Native to SST data stream | Native to data stream | Defined by data provider | Defined by data provider | Defined by data provider | | Delivery timescale | As available, Ideally within 3 hours from acquisition at satellite | As available, Ideally within 3 hours from acquisition at satellite | As available, Ideally within 3 hours from acquisition at satellite | As available, Ideally within 3 hours from acquisition at satellite | Analyzed product processing window as defined by data provider. | | Target accuracy | Native to data stream | Native to data stream | <0.4 K | <0.4 K | < 0.4 K absolute, 0.1 K relative | | Error statistics | Native to data stream if available, sensor specific error statistics otherwise | Native to data stream if available, sensor specific error statistics otherwise | Derived from input data for each output grid point. | Derived from input data for each output grid point. | Analysis error defined by data provider for each output grid point (no input data statistics are retained) | | Coverage | Native to data stream | Native to data stream | Defined by data provider | Defined by data provider | Defined by data provider | L3 GHRSST products do not use analysis or interpolation procedures to fill gaps where no observations are available [^footnote0]: Donlon, C. J., I. Robinson, K. S Casey, J. Vazquez-Cuervo, E Armstrong, O. Arino, C. Gentemann, D. May, P. LeBorgne, J. Piollé, I. Barton, H Beggs, D. J. S. Poulter, C. J. Merchant, A. Bingham, S. Heinz, A Harris, G. Wick, B. Emery, P. Minnett, R. Evans, D. Llewellyn-Jones, C. Mutlow, R. Reynolds, H. Kawamura and N. Rayner, 2007. The Global Ocean Data Assimilation Experiment (GODAE) high Resolution Sea Surface Temperature Pilot Project (GHRSST-PP). Bull. Am. Meteorol. Soc., Vol. 88, No. 8, pp. 1197-1213, https://doi.org/10.1175/BAMS-88-8-1197 [^footnote1]: Global Climate Observing system, 2004. Implementation plan for the Global observing system for climate in support of the UNFCCC, GCOS – 92, WMO/TD No. 1219, available from World Meteorological Organization. [^footnote2]: The Second Report on the Adequacy of the Global Observing Systems for Climate in Support of the UNFCCC, GCOS – 82, April 2003 (WMO/TD No. 1143), Available online at http://www.wmo.int/pages/prog/gcos/index.php [^footnote3]: Satellite Observation of the Climate System: The Committee on Earth Observation Satellites (CEOS) Response to the Global Climate Observing System (GCOS) Implementation Plan, Available online at http://www.ceos.org/pages/CEOSResponse_1010A.pdf [^footnote4]: Donlon, C. J., P. Minnett, C. Gentemann, T. J. Nightingale, I. J. Barton, B. Ward and, J. Murray, 2002. Towards Improved Validation of Satellite Sea Surface Skin Temperature Measurements for Climate Research, J. Climate, Vol. 15, No. 4, pp. 353-369. _sources/naming.md0000664000175000017500000004770514725077514014720 0ustar jfpiollejfpiolle# GDS Filenames and Supporting Conventions Striving to achieve a flexible naming convention that maintains consistency across processing levels and better serves user needs, the GDS uses a single form for all GHRSST data files. An overview of the format is presented below in {numref}`overview_filenaming` along with example filenames. Details on each of the filename convention components are provided in {numref}`indicative_date` through {numref}`segregator`. In addition, a best practice has been established for creating character strings used to describe GHRSST SST products and sources of ancillary data. These strings, and associated numeric codes for the SST products, are used within some GHRSST data files but are not part of the filename convention itself. The best practice is described in {numref}`product_codes`. (overview_filenaming)= ## Overview of Filename Convention and Example Filenames The filenaming convention for the GDS {{gds_version}} is shown below: **`--_GHRSST----v-fv.`** The variable components within braces (“< >”) are summarized in {numref}`filenaming_components` below and detailed in the following sections. Note that dashes (“-“) **are reserved** to separate elements of the file name and **should not** be used in any GHRSST code or the `` element. Example filenames are given later in this section. While no strict limit to filename length is mandated, RDACs are encouraged to keep the length to less than 240 characters to increase readability and usability. ```{table} Filenaming convention components. :name: filenaming_components **Name**|**Definition**|**Description** -----|-----|----- ``|YYYYMMDD|The identifying date for this data set. See {numref}`indicative_date`. ``|HHMMSS|The identifying time for this data set. The time used is dependent on the of the data set:
  L2P: start time of granule
  L3U: start time of granule
  L3C and L3S: centre time of the collation window
  L4 and GMPE: nominal time of analysis
All times should be given in UTC. See {numref}`indicative_time`. ``|The RDAC where the file was created|The Regional Data Assembly Centre (RDAC) code, listed in the GHRSST reference tables at {{gds_reference_tables}}. See {numref}`rdac`. ``|The data processing level code (L2P, L3U, L3C, L3S, or L4)|The data processing level code, defined in {numref}`processing_levels`. ``|The type of SST data included in the file.|Conforms to the GHRSST definitions for SST, defined in {numref}`sst_type`. ``|A character string identifying the SST product set. The string is used uniquely within an RDAC but may be shared across RDACs.|The unique “name” within an RDAC of the product line. See {numref}`product_codes` for the product string lists, one each for L2P, L3, L4, and GMPE products. See {numref}`product_string`. ``|Optional text to distinguish between files with the same . Dashes are not allowed within this element.|This text is used since the other filename components are sometimes insufficient to uniquely identify a file. For example, in L2P or L3U (un-collated) products this is often the original file name or processing algorithm. Note, underscores should be used, not dashes. For L4 files, this element should begin with the appropriate regional code as defined in Section . This component is optional but must be used in those cases were non-unique filenames would otherwise result. ``|nn.n |Version number of the GDS used to process the file. For example, GDS-2.1 = “02.1”. ``|xx.x|Version number for the file, for example, “01.0”. ``|netCDF data file suffix (nc) or ISO metadata file suffix (xml)|Indicates this is a netCDF file containing data or its corresponding ISO-19115 metadata record in XML. ``` **L2_GHRSST Filename Example** `20070503132300-NAVO-L2P_GHRSST-SSTblend-AVHRR17_L-SST_s0123_e0135-v02.1-fv01.0.nc` The above file contains GHRSST L2P blended SST data for 03 May 2007, from AVHRR LAC data collected from the NOAA-17 platform. The granule begins at 13:23:00 hours. It is version 1.0 of the file and was produced by the NAVO RDAC in accordance with the GDS {{gds_version}}. The `` text is "SST_s0123_e0135". **L3_GHRSST Filename Example** `20070503110153-REMSS-L3C_GHRSST-SSTsubskin-TMI-tmi_20070503rt-v02.1-fv01.0.nc` The above file was produced by the REMSS RDAC and contains collated L3 sub-skin SST data from the TMI instrument for 03 May 2007. The collated file has a centre time of at 11:01:53 hours. It is version 1.0 of the file and was produced according to GDS {{gds_version}} specifications. Its `` text is “tmi_20070503rt”. **L4_GHRSST Filename Example** `20070503120000-UKMO-L4_GHRSST-SSTfnd-OSTIA-GLOB-v02.1-fv01.0.nc` The above file contains L4 foundation SST data produced at the UKMO RDAC using the OSTIA system. It is global coverage, contains data for 03 May 2007, was produced to GDS {{gds_version}} specifications and is version 1.0 of the file. The nominal time of the OSTIA analysis is 12:00:00 hours. (indicative_date)= ## `` The identifying date for this data set, using the format YYYYMMDD, where YYYY is the four-digit year, MM is the two-digit month from 01 to 12, and DD is the two-digit day of month from 01 to 31. The date used should best represent the observation date for the dataset. (indicative_time)= ## `` The identifying time for this data set in UTC, using the format HHMMSS, where HH is the two-digit hour from 00 to 23, MM is the two-digit minute from 00 to 59, and SS is the two-digit second from 00 to 59. The time used is dependent on the `` of the data set: - L2P: start time of granule - L3U: start time of granule - L3C and L3S: centre time of the collation window - L4 and GMPE: nominal time of analysis All times should be given in UTC and should be chosen to best represent the observation time for this dataset. Note: RDACs should ensure the applications they use to determine UTC proprerly account for leap seconds. (rdac)= ## `` Codes used for GHRSST Regional Data Assembly Centres (RDACs) are available on the GHRSST website (https://www.ghrsst.org/resources/ghrsst-data-specification-gds-tables/). New codes are assigned by the GHRSST Data And Systems Technical Advisory Group (DAS-TAG) and entered into the table upon agreement by the GDAC, LTSRF, and relevant RDACs. (processing_levels)= ## `` Satellite data processing level definitions can lead to ambiguous situations, especially regarding the distinction between L3 and L4 products. GHRSST identified the use of analysis procedures to fill gaps where no observations exist to resolve this ambiguity. Within GHRSST filenames, the `` codes are shown below in {numref}`processing_level`. GHRSST currently establishes standards for L2P, L3U, L3C, L3S, and L4 (GHRSST Multi-Product Ensembles known as GMPE are a special kind of L4 product for which GHRSST also provides standards). ```{table} GHRSST Processing Level Conventions and Codes :name: processing_level **Level**|** Code**|**Description** :-----:|:-----:|:-----: Level 0|L0|Unprocessed instrument and payload data at full resolution. GHRSST does not make recommendations regarding formats or content for data at this processing level. Level 1A|L1A|Reconstructed unprocessed instrument data at full resolution, time referenced, and annotated with ancillary information, including radiometric and geometric calibration coefficients and geo-referencing parameters, computed and appended, but not applied, to L0 data. GHRSST does not make recommendations regarding formats or content for data at this processing level. Level 1B|L1B|Level 1A data that have been processed to sensor units. GHRSST does not currently make recommendations regarding formats or content for L1B data. Level 2 Pre-processed|L2P|Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates. Level 3|L3U L3C L3S|Level 2 variables mapped on a defined grid with reduced requirements for ancillary data. Uncertainty estimates are still mandatory. Three types of L3 products are defined: Un-collated (L3U): L2 data granules remapped to a space grid without combining any observations from overlapping orbits Collated (L3C): observations combined from a single instrument into a space-time grid Super-collated (L3S): observations combined from multiple instruments into a space-time grid. Note that L3 GHRSST products do not use analysis or interpolation procedures to fill gaps where no observations are available. Level 4|L4|Data sets created from the analysis of lower level data that result in gridded, gap-free products. SST data generated from multiple sources of satellite data using optimal interpolation are an example of L4 GHRSST products. GMPE products are a type of L4 dataset. ``` Note that within GHRSST, all L2P files require a full set of extensive ancillary data such as wind speeds and times of observation that are provided as ‘dynamic flags’ that users can manipulate to filter data according to their own quality criteria. L2P files form the basis of higher-level products and are often the best level products for data assimilation. The requirement for dynamic flags is particularly important in this context. Higher-level L3 products are often intended for general use or created for input to Level 4 analysis systems so the requirement for extensive ancillary data is reduced. Since some GHRSST RDACs only process data natively on grids (especially in the case of geostationary platform observations), the GDS {{gds_version}} L3 specification is flexible enough to allow for the creation of L3 files which meet all the content requirements of a L2P file. In all L2P and L3 cases, bias and standard deviation uncertainty estimates are mandatory. The distinction between L3 GHRSST and L4 GHRSST data is made primarily on whether or not any gap-filling techniques are employed, not on whether data from multiple instruments is used in the L3 product. If no gap filling procedure (such as optimal interpolation) is used, then the product remains a L3 GHRSST product. GHRSST defines three kinds of L3 files: un-collated (L3U), collated (L3C), and super-collated (L3S). If gap filling is used to fill all observations gaps, then the resulting gap-free data are considered L4 GHRSST data products. (sst_type)= ## `` In conjunction with the NetCDF Climate and Forecast (CF) community [AD-9] the GHRSST Science Team agreed on the CF standard names for “SST” shown in the following figure and described in more detail below. The names were first included in CF-1.3, and the current version of the standard name table can be found in [AD-8]. In addition, the GHRSST Science Team agreed to use the CF Naming Convention [AD-3] for variable names that do not already exist as part of the CF Convention. CF definitions are used in the GDS and across GHRSST and are shown schematically in {numref}`sst_definition`. The different kinds of SST are detailed later in this section and the relevant `` codes to be used in the filenames are provided. The SST codes and CF standard names defined above and used within GHRSST are summarized along with their key characteristics in {numref}`sst_types`. ```{table} GHRSST SST Type code and summary table :name: sst_types **GHRSST SST Type**|**CF Standard Name**|**Approximate Depth**|**Typically Observed by…** -----|-----|-----|----- SSTint|**sea\_surface\_temperature**|0 meters|Not presently measureable SSTskin|**sea\_surface\_skin\_temperature**|10 – 20 micrometers|Infrared radiometers operating in a range of wavelengths form 3.7 to 12 micrometers SSTsubskin|**sea\_surface\_subskin\_temperature**|1 – 1.5 millimetres|Microwave radiometers operating in a range of frequencies from 6-11 gigahertz SSTdepth|**sea\_water\_temperature**|Specified by vertical coordinate (e.g., SST5m)|In situ observing systems SSTfnd|**sea\_surface\_foundation\_temperature**|1-5 meters pre-dawn|In situ observing systems SSTblend|None|Unknown|Blend of satellite and in situ observations ``` (product_string)= ## `` The product strings are used within the GHRSST filename convention and within the GHRSST unique data set codes described in {numref}`product_codes`. The satellite platform and satellite sensor entries are also used in the netCDF global attributes, `platform` and `instrument` GHRSST product files. See {numref}`global_attributes` for more information on the required **global attributes**. In order to improve the consistency of these product strings across producers, and avoid maintaining specific GHRSST tables, we recommend to use the CEOS tables as vocabulary for satellite platform and satellite name: - CEOS platform table: http://database.eohandbook.com/database/missiontable.aspx - CEOS sensor table: http://database.eohandbook.com/database/instrumenttable.aspx ```{note} unfitted characters for file naming (like / or spaces) can be replaced with -. ``` The following code nomenclature is recommended for the single sensor products: `_(_)` As an example, a product string for a METOP-A AVHRR product would be : _Metop-A\_AVHRR-3_ (segregator)= ## `` It is possible for the preceding combination of filename components to result in a non-unique filename for any GHRSST product level. In those situations, the use of the `` must be used to ensure each distinct file has a unique file name. In addition, RDACs are free to use this component to add other information to their file names. Some providers, for example, use the name of the original L1b file. Others enter start and stop times of the file in this component. Note that in the case of GHRSST L4 files the `` element must begin with a code that specifies the approximate region covered by the SST analysis product. There are two primary reasons for this requirement, the first of which is to ensure uniqueness in the file names in the cases where an RDAC is using the same L4 analysis system (for example, “ODYSSEA”) to create products for multiple regions (for example, “GAL” (Galapagos Islands Region) and “MED” (Mediterranean Region)). The second reason is that users need to quickly identify at a glance the approximate domain of the L4 products. Users should note that the geographical coordinates associated with each area code are explicitly intended to be only approximate, and not strict. For example, an RDAC producing a near-global coverage data may choose to only produce data on a grid that extends to 85°S. Such a product would use the “GLOB” code. Users must retrieve the precise latitude and longitude limits directly from the L4 netCDF data files. (product_codes)= ## GHRSST Unique Text Strings and Numeric Codes This section describes the best practices that have been developed for creating unique text strings and numeric codes that are needed in various places within some GHRSST files. Note that these strings are not part of the filename convention described above, but, like filenames, they apply to all GHRSST product levels and so are described in this part of the GDS. ### SST Variable Text Strings and Numeric Codes For each official GHRSST product, a unique numeric code and associated text string is defined. The string is listed in the global attribute id (see Section 8.2) for each netCDF file in the product collection. The unique numerical values and text strings for GHRSST SST datasets are established by agreement between the relevant RDAC, GDAC, and the LSTRF, following the Best Practice defined later in this section. The GHRSST L2P, L3, L4 and GMPE product specifications ({numref}`l2p`, {numref}`l3`, {numref}`l4`, and 12, respectively) also require the providing RDAC to use these text strings directly within the netCDF global attribute **source** to indicate the sources of SST used to create the product. In the event that a non-GHRSST dataset is used as a source, as in the case of an L2P product that uses a Level 1 dataset as its source, it too must have an established text string following the best practice below (to the extent possible). The associated numeric codes are used in some L3S files, which must describe the SST sources pixel-by-pixel in a variable named **source_of_sst** if more than one SST source is used. If only one source is used, the variable **source_of_sst** is not needed and instead the source is indicated simply by using the text string in the global attribute **source** (see Section 8.2 and Section 10.29) as indicated earlier. ### Ancillary and Optional Variable Text Strings and Numeric Codes GHRSST L2P, L3, L4 and GMPE product specifications ({numref}`l2p`, {numref}`l3`, {numref}`l4`, and 12, respectively) also require the providing RDAC to indicate text strings and associated numeric codes directly within the netCDF global and variable attributes for the sea surface temperature or ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, wind speed, and when relevant, for optional and experimental variables. These text strings and codes do not need to be unique across different data sets, but must be consistent within a given data set and clearly specified within each netCDF file. In these cases, the variable in question should contain an attribute called **flag_meanings** together with a variable called **flag_values**. The **flag_values** attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the **flag_meanings** attribute. ### Best Practice for Establishing Character Strings A best practice has been established for defining the text strings to be used in these GHRSST attributes. While a rigid standard for the text strings is not possible, the following best practice should be applied to the extent possible for GHRSST SST datasets and the ancillary and optional variables: `----v` The definitions of the components match the definitions from the file naming convention, found in {numref}`filenaming_components`. The component `` is used to distinguish different versions of the same dataset and should be of the form x.y where x is the major and y is the minor version. For ancillary and optional variables, an attempt should be made to follow these conventions to the extent possible. If there is no appropriate GHRSST RDAC to use in the string, then it is recommended that a commonly used acronym for the centre responsible be used. It is recommended that the `` should be one of ICE, ADI, CLIM, SSI, and WSP, for ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, and wind speed variables, respectively. Notethat many SST text strings not meeting this best practice were established under the GDS version 1 and are already in use. These codes are used in the GHRSST Central Catalogue as product identifiers. _sources/sea_surface_temperature.md0000664000175000017500000002555214625571675020346 0ustar jfpiollejfpiolle# Sea Surface Temperature SST is a challenging parameter to define precisely as the upper ocean (~10 m) has a complex and variable vertical temperature structure that is related to ocean turbulence and air-sea fluxes of heat, moisture and momentum. A theoretical framework is therefore required to understand the information content and relationships between measurements of SST made by different satellites and in situ instruments, especially if these are to be merged together. The definitions of SST developed by the GHRSST SST Science Team (agreed at the 2nd and 3rd workshops) achieve the closest possible coincidence between what is defined and what can be measured, taking into account current scientific knowledge and understanding of the near-surface thermal structure of the ocean. The definitions of SST defined by GHRSST are currently being refined by the Science Team. Once approved, the GHRSST SST definitions will be iterated with the Climate and Forecast (CF) metadata convention definitions of SST to ensure they are in agreement. The figure below presents a schematic diagram that summarises the definition of SST in the upper 10 m of the ocean and provides a framework to understand the differences between complementary SST measurements. It encapsulates the effects of dominant heat transport processes and time scales of variability associated with distinct vertical and volume regimes of the upper ocean water column (horizontal and temporal variability is implicitly assumed). ```{figure} images/sst-definition.gif --- name: sst_definition --- Overview of SST measurement types used within GHRSST ``` CF Definition: > sea_surface_temperature is usually abbreviated as "SST". It is the temperature of sea water near the surface (including the part under sea-ice, if any), and not the interface temperature, whose standard name is surface_temperature. For the temperature of sea water at a particular depth or layer, a data variable of sea_water_temperature with a vertical coordinate axis should be used. ```{admonition} Additional details The interface temperature (SSTint) is a theoretical temperature at the precise air-sea interface. It represents the hypothetical temperature of the topmost layer of the ocean water and could be thought of as an even mix of water and air molecules. SSTint is of no practical use because it cannot be measured using current technology. It is important to note that it is the SSTint that interacts with the atmosphere. Within GHRSST, most variables containing SST are named “sea_surface_temperature” to simplify the development of client applications wishing to read these variables. The variable attribute “standard_name” indicates the precise form of the SST, using the following definitions. More detail is given in the Level 2P (Section 9), Level 3 (Section 10), and Level 4 (Section 11) specification. ``` **Sea_surface_skin_temperature (GHRSST : SSTskin):** CF Definition: > The surface called "surface" means the lower boundary of the atmosphere. The sea surface skin temperature is the temperature measured by an infrared radiometer typically operating at wavelengths in the range 3.7 - 12 micrometers. It represents the temperature within the conductive diffusion-dominated sub-layer at a depth of approximately 10 - 20 micrometers below the air-sea interface. Measurements of this quantity are subject to a large potential diurnal cycle including cool skin layer effects (especially at night under clear skies and low wind speed conditions) and warm layer effects in the daytime. ```{admonition} Additional Details: The sea surface skin temperature (SSTskin) as defined above represents the actual temperature of the water across a very small depth of approximately 20 micrometers. This definition is chosen for consistency with the majority of infrared satellite and ship mounted radiometer measurements. ``` **Sea_surface_subskin_temperature (GHRSST : SSTsubskin):** CF Definition: > The surface called "surface" means the lower boundary of the atmosphere. The sea surface subskin temperature is the temperature at the base of the conductive laminar sub-layer of the ocean surface, that is, at a depth of approximately 1 - 1.5 millimetres below the air-sea interface. For practical purposes, this quantity can be well approximated to the measurement of surface temperature by a microwave radiometer operating in the 6 - 11 gigahertz frequency range, but the relationship is neither direct nor invariant to changing physical conditions or to the specific geometry of the microwave measurements. Measurements of this quantity are subject to a large potential diurnal cycle due to thermal stratification of the upper ocean layer in low wind speed high solar irradiance conditions. ```{admonition} Additional Details: The sea surface subskin temperature (SSTsubskin) represents the temperature at the base of the thermal skin layer. The difference between SSTint and SSTsubskin is related to the net flux of heat through the thermal skin layer. SSTsubskin is the temperature of a layer approximately 1 mm thick at the ocean surface. ``` **Sea_water_temperature (GHRSST : SSTdepth or SSTz):** CF Definition: > The general term, "bulk" sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable. ```{admonition} Additional Details: Sea water temperature (SSTdepth or SSTz, for example SST1.5m) is the terminology adopted by GHRSST to represent in situ measurements near the surface of the ocean that have traditionally been reported simply as SST or "bulk" SST. For example SST6m would refer to an SST measurement made at a depth of 6 m. Without a clear statement of the precise depth at which the SST measurement was made, and the circumstances surrounding the measurement, such a sample lacks the information needed for comparison with, or validation of satellite-derived estimates of SST using other data sources. The terminology has been introduced to encourage the reporting of depth (z) along with the temperature. ``` All measurements of water temperature beneath the SSTsubskin are obtained from a wide variety of sensors such as drifting buoys having single temperature sensors attached to their hull, moored buoys that sometimes include deep thermistor chains at depths ranging from a few meters to a few thousand meters, thermosalinograph (TSG) systems aboard ships recording at a fixed depth while the vessel is underway, Conductivity Temperature and Depth (CTD) systems providing detailed vertical profiles of the thermohaline structure used during hydrographic surveys and to considerable depths of several thousand meters, and various expendable bathythermograph systems (XBT). In all cases, these temperature observations are distinct from those obtained using remote sensing techniques and measurements at a given depth should be referred to as sea_water_temperature qualified by a depth in meters rather than sea surface temperatures. The situation is complicated further when one considers ocean model outputs for which the SST may be the mean SST over a layer of the ocean several tens of meters thick. **Sea_surface_foundation_temperature (GHRSST : SSTfnd):** CF Definition: > The surface called "surface" means the lower boundary of the atmosphere. The sea surface foundation temperature is the water temperature that is not influenced by a thermally stratified layer of diurnal temperature variability (either by daytime warming or nocturnal cooling). The foundation temperature is named to indicate that it is the temperature from which the growth of the diurnal thermocline develops each day, noting that on some occasions with a deep mixed layer there is no clear foundation temperature in the surface layer. In general, sea surface foundation temperature will be similar to a night-time minimum or pre-dawn value at depths of between approximately 1 and 5 meters. In the absence of any diurnal signal, the foundation temperature is considered equivalent to the quantity with standard name sea_surface_subskin_temperature. The sea surface foundation temperature defines a level in the upper water column that varies in depth, space, and time depending on the local balance between thermal stratification and turbulent energy and is expected to change slowly over the course of a day. If possible, a data variable with the standard name sea_surface_foundation_temperature should be used with a scalar vertical coordinate variable to specify the depth of the foundation level. Sea surface foundation temperature is measured at the base of the diurnal thermocline or as close to the water surface as possible in the absence of thermal stratification. Only in situ contact thermometry is able to measure the sea surface foundation temperature. Analysis procedures must be used to estimate sea surface foundation temperature value from radiometric satellite measurements of the quantities with standard names sea_surface_skin_temperature and sea_surface_subskin_temperature. Sea surface foundation temperature provides a connection with the historical concept of a "bulk" sea surface temperature considered representative of the oceanic mixed layer temperature that is typically represented by any sea temperature measurement within the upper ocean over a depth range of 1 to approximately 20 meters. The general term, "bulk" sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. Sea surface foundation temperature provides a more precise, well-defined quantity than "bulk" sea surface temperature and, consequently, is more representative of the mixed layer temperature. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable. ```{admonition} Additional Details: Through the definition of the CF standard names, GHRSST is attempting to discourage the use of the term “bulk SST”, replacing it instead with sea_water_temperature (SSTdepth) and a depth coordinate, or sea_surface_foundation_temperature (SSTfnd) and a depth coordinate if possible, if the observation comes from the base of the diurnal thermocline. ``` **Blended SST (GHRSST : SSTblend):** In addition to the CF standard names defined above, GHRSST also uses the term “Blended SST” for ambiguous cases when the depth or type of SST is not well known. This ambiguity in depth may arise in some L4 analysis products that merge multiple types of SST from satellite and in situ observations. Note, however, that many L4 analysis systems do attempt to specifically create a sea surface foundation temperature, SSTfnd. _sources/l3.md0000664000175000017500000007676214744701271013765 0ustar jfpiollejfpiolle--- jupytext: formats: md:myst text_representation: extension: .md format_name: myst --- (l3)= # Level 3 (L3) Product Specification ## Overview description of the GHRSST L3 data product GHRSST L3 data have been introduced to provide users with gridded, synthetic, and potentially adjusted SST products, bringing added value with respect to the original L2P but still allowing traceability to the original dataset. GHRSST L3 products do not use analysis or interpolation procedure to fill gaps where no observations are available. The GHRSST L3 products include: - **Un-collated** data that represent a straightforward remapping of L2P GHRSST data granules to a space grid without combining any observations from overlapping orbits or times. Although in principle these data may or may not be adjusted to a reference sensor, in practice the un-collated L3 will normally be a remapped L2P dataset. For remapping best practices of L2P on a grid, see {numref}`l2_remapping_best_practice`. - **Collated** data that grid observations from a single instrument and a single platform into space and/or time bins. These data may or may not be adjusted to a reference sensor. For collating best practices, see {numref}`collating_best_practice` and for adjustment best practices see {numref}`adjustment_best_practice`. - **Super-collated** data that combine observations from a multiple instruments into a space-time grid. In this case, the adjustment to a common reference is necessary to avoid heterogeneities in the resulting field. For best practices concerning the creation of super collated files see {numref}`supercollating_best_practice` As a result, the format of a L3 file will be able to cope with the three kinds of L3 SST presented above. The L3 format will include the following parts: 1. **In case the L3 is un-adjusted**, a mandatory section containing the original L2P information remapped onto the grid point: the original sea surface temperature, quality level and SSES information. An optional section including the remapping condition information may also be provided. These files are essentially gridded L2P files. 2. **In case the L3 is adjusted to a reference**, the adjusted SST value must be provided, together with the local bias to the reference, the error generated by the adjustment processing, and the overall error resulting from the combination of the SSES and the adjustment processing error. 3. **In case the L3 is super-collated**, the source of SST at each pixel is mandatory. **Un-adjusted files**: In the case of **un-collated or collated un-adjusted L3 files** the L3 file is derived from L2P data by a remapping process. The remapping and collating best practices are given in {numref}`l2_remapping_best_practice`. Their content is thus identical to that of the L2P, but complementary, optional information on the remapping conditions may be provided. **Adjusted files**: Collated files may or may not be adjusted, but a super-collated file is necessarily adjusted. The super-collating and adjustment best practices are described in {numref}`collating_best_practice` and {numref}`adjustment_best_practice`. The principle governing this format is to allow traceability to the original L2P, while providing the best-adjusted SST value. A first section (in blue in {numref}`l3_content`) reproduces the original L2P SST and SSES information as in the un-adjusted version. The reference used to adjust the SST must be given in the “reference” attribute of the `adjusted_sea_surface_temperature` variable. The adjusted SST and some error information are also mandatory. This information, in yellow in {numref}`l3_content`, is: - `adjusted_standard_deviation_error`: the total error resulting from the combination of the SSES error and the adjustment procedure error, `standard_deviation_to_reference_sst`. - `bias_to_reference_sst`: the local value of the estimated difference between the original SST and the reference SST - `standard_deviation_to_reference_sst`: an estimate of the error resulting from the adjustment procedure. If the procedure consists of analysing a field of differences of original SST and reference SST, the `standard_deviation_to_reference_sst` will be the error of this analysis. The GHRSST Science Team determined that 5 mandatory fields will form the core data content of a GHRSST L3 data file. In addition to global attributes and geo-location information, GHRSST producers must provide the following within a L3 file: - Sea Surface temperature data (SST), - Time of SST measurement, - Bias and Standard Deviation error estimates for SST data, - Data quality. There are a number of optional fields that may be used at the data provider’s discretion that will form the core data content of a GHRSST data file ({numref}`l3_data_records`). The GHRSST L3 file contents are summarized in {numref}`l3_content` below. ```{table} Summary description of the contents within a GHRSST L3 data product :name: l3_content :class: l3-content-css | netCDF File Contents | Description | |----------------------|-----------------------------------------------------------------------------------------------------------| | **Coordinate variables** | Information to permit locating data on grids, as defined in {numref}`coordinate_variables` | | **L2P Data record variables** | Core and auxiliary variables as defined in {numref}`l2p_records` | | **L3 Data record variables** | Special Level 3 variables as defined in {numref}`l3_data_records` | | **Global Attributes** | A collection of required global attributes describing general characteristics of the file, as defined in section {numref}`global_attributes` | ``` ## L3 data record format specification This table provides an overview of the GHRSST L3 product pixel data record that should be created for each input data. Within GHRSST L3 data files, there are many variables that are defined identically to their L2P counterparts. In addition, there are several variables that are unique to L3. Both types are listed below in {numref}`l3_data_records`. In the following sections, each variable within the L3 data file that is unique to L3 is described in detail. ```{table} Summary description of GHRSST L2P data records :name: l3_data_records :class: l3-variables-css | Variable Name | Description | Units | Storage type | |-----------------------|------------------------|--------|-----| | [sea_surface_temperature](__l2p_sea_surface_temperature) | SST measurement values from input L2 satellite data set. | K (kelvin) | short | | [sst_dtime](__l2p_sst_dtime) | The deviation in time of SST measurement from reference time | s (second)| short | | [sses_bias](__l2p_sses_bias) | Sensor Specific Error Statistic (SSES) bias error | K (kelvin)| byte | | [sses_standard_deviation](__l2p_sses_standard_deviation) | Sensor Specific Error Statistic (SSES) standard deviation uncertainty | K (kelvin)| byte | | [dt_analysis](__l2p_dt_analysis) | The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period | K (kelvin)| byte or short| | [wind_speed](__l2p_wind_speed) | Closest (in time) 10 m surface wind speed from satellite or analysis | m s-1 | byte | | [wind_speed_dtime_from_sst](__l2p_wind_speed_dtime_from_sst) | Time difference of `wind_speed` data from input L2 SST measurement specified in hours.| h (hour) | byte | | [source_of_wind_speed](__l2p_source_of_wind_speed) | Source(s) of `wind_speed` data. Mandatory when multiple sources used. | Code| byte | | [sea_ice_fraction](__l2p_sea_ice_fraction) | Closest (in time) sea ice fraction from satellite or analysis | 1 | byte | | [sea_ice_fraction_dtime_from_sst](__l2p_sea_ice_fraction_dtime_from_sst) | Time difference of `sea_ice_fraction` data from input L2 SST measurement specified in hours| h (hour)| byte | | [source_of_sea_ice_fraction](__l2p_source_of_sea_ice_fraction) | Source(s) of `sea_ice_fraction` data | code | byte | | [aerosol_dynamic_indicator](__l2p_aerosol_dynamic_indicator) | Atmospheric aerosol indicator | | byte | | [adi_dtime_from_sst](__l2p_adi_dtime_from_sst) | Time difference between the `aerosol_dynamic_indicator` value and SST measurement | h (hour) | byte | | [source_of_adi](__l2p_source_of_adi) | Source(s) of atmospheric aerosol indicator data | code | byte | | [l2p_flags](__l2p_l2p_flags) | Data flag values | mask of bits | short | | [quality_level](__l2p_quality_level) | Overall indication of L2P data quality | enum | byte | | [satellite_zenith_angle](__l2p_satellite_zenith_angle) | Calculated satellite zenith angle (measured at the Earth's surface between the satellite and the zenith)| degree | byte | | [solar_zenith_angle](__l2p_solar_zenith_angle) | Calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth's surface)| degree | byte | | [surface_solar_irradiance](__l2p_surface_solar_irradiance) | Near contemporaneous surface solar irradiance| W m-2| byte | | [ssi_dtime_from_sst](__l2p_ssi_dtime_from_sst) | Time difference between the `surface_solar_irradiance` value and SST measurement in hours | h (hour)| byte | | [source_of_ssi](__l2p_source_of_ssi) | Source(s) of `surface_solar_irradiance` data | code | byte | | [or_latitude](__l3_or_latitude) |Original latitude of the satellite measurement as provided in the L2P| degree_north | short or float| | [or_longitude](__l3_or_longitude) |Original longitude of the satellite measurement as provided in the L2P |degree_east | short or float| | [or_number_of_pixels](__l3_or_number_of_pixels) |Number of original pixels from the L2P contributing to the binned (space and/or time) average| 1 (unitless) | short| | [sum_sst](__l3_sum_sst) |Sum of the pixel values going into the space and/or time bin | K (kelvin) | float| | [sum_square_sst](__l3_sum_square_sst) | Sum of the pixel value squares going into the space and/or time bin | K2 (kelvin^2) | float| | [adjusted_sea_surface_temperature](__l3_adjusted_sea_surface_temperature) |SST adjusted to the reference. Mandatory for adjusted type file | K (kelvin) | short| | [adjusted_standard_deviation_error](__l3_adjusted_standard_deviation_error) |Total error standard deviation estimate derived from SSES and adjustment method. Mandatory for adjusted type file | K (kelvin) |byte| | [bias_to_reference_sst](__l3_bias_to_reference_sst) |Bias error derived from comparison with the reference. Mandatory for adjusted type file | K (kelvin) | short| | [standard_deviation_to_reference_sst](__l3_standard_deviation_to_reference_sst) |Error standard deviation resulting from the bias estimation method. Mandatory for adjusted type file | K (kelvin) | byte| | [source_of_sst](__l3_source_of_sst) |Source of SST data. Mandatory for super-collated type file |code | byte| | [other fields](__l2p_optional_fields) | Optional/experimental fields defined by data provider | | | ``` (__l3_or_latitude)= ### `or_latitude` **Optional.** This variable is the original latitude of the contributing pixel in case of remapping to the nearest pixel, or the average latitude of the contributing pixels in case of averaging. The variable `or_latitude` will be included either as a floating point variable similarly to the grid latitude and longitude, or as a short variable, with the format requirements shown in {numref}`l3_or_latitude`, if the required precision is compatible. ```{table} CDL example description of **or_latitude** variable :name: l3_or_latitude | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short or float | `or_latitude` | Original latitude of the satellite measurement | degree_north | ``` ```{code-cell} :tags: [remove-input] :name: l3_or_latitude !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]or_latitude[(,:]'| sed 's/[[:space:]]//' ``` (__l3_or_longitude)= ### `or_longitude` **Optional.** This variable is the original longitude of the contributing pixel in case of remapping to the nearest pixel, or the average longitude of the contributing pixels in case of averaging. The variable `or_longitude` shall be included either as a floating point variable similarly to the grid latitude and longitude, or as a short variable, with the format requirements shown in {numref}`l3_or_longitude`, if the required precision is compatible. ```{table} CDL example description of **or_longitude** variable :name: l3_or_longitude | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short or float | `or_longitude` | Original longitude of the satellite measurement | degree_east | ``` ```{code-cell} :tags: [remove-input] :name: l3_or_longitude !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]or_longitude[(,:]'| sed 's/[[:space:]]//' ``` (__l3_or_number_of_pixels)= ### `or_number_of_pixels` **Mandatory.** This variable is the number of original pixels from the L2P contributing to the binned (space and/or time) average. The variable `or_number_of_pixels` shall be included with the format requirements shown in {numref}`l3_or_number_of_pixels`. ```{table} CDL example description of **or_number_of_pixels** variable :name: l3_or_number_of_pixels | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `or_number_of_pixels` | Number of pixels from the L2P contributing to the SST value | "1" (unitless) | ``` ```{code-cell} :tags: [remove-input] :name: l3_or_number_of_pixels !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]or_number_of_pixels[(,:]'| sed 's/[[:space:]]//' ``` (__l3_sum_sst)= ### `sum_sst` **Optional.** This variable is the sum of the original SST pixel values contributing to the binned (space and/or time) average. The variable `sum_sst` shall be included with the format requirements shown in {numref}`l3_sum_sst`. ```{table} CDL example description of **sum_sst** variable :name: l3_sum_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `sum_sst` | Sum of the pixel values going into the space and/or time bin | K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l3_sum_sst !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]sum_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l3_sum_square_sst)= ### `sum_square_sst` **Optional.** This variable is the sum of the squares of the original SST pixel values contributing to the binned (space and/or time) average. The variable `sum_square_sst` shall be included with the format requirements shown in {numref}`l3_sum_square_sst`. ```{table} CDL example description of **sum_square_sst** variable :name: l3_sum_square_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `sum_square_sst` | Sum of the pixel value squares going into the space and/or time bin | K2 | ``` ```{code-cell} :tags: [remove-input] :name: l3_sum_square_sst !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]sum_square_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l3_adjusted_sea_surface_temperature)= ### `adjusted_sea_surface_temperature` **Mandatory for adjusted type files.** This variable is the SST adjusted to the reference. See the principles of the adjustment procedure in {numref}`adjustment_best_practice`. The variable `adjusted_sea_surface_temperature` shall be included with the format requirements shown in {numref}`l3_adjusted_sea_surface_temperature`. ```{table} CDL example description of **adjusted_sea_surface_temperature** variable :name: l3_adjusted_sea_surface_temperature | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `adjusted_sea_surface_temperature` | SST values after adjustment to the reference|K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l3_adjusted_sea_surface_temperature !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]adjusted_sea_surface_temperature[(,:]'| sed 's/[[:space:]]//' ``` (__l3_adjusted_standard_deviation_error)= ### `adjusted_standard_deviation_error` **Mandatory for adjusted type files.** This variable represents the total error associated with the `adjusted_sea_surface_temperature` variable. It represents the accumulated error of the SST production (the `sses_standard_deviation`) and the SST adjustment (`standard_deviation_to_reference_sst`). The variable `adjusted_standard_deviation_error` shall be included with the format requirements shown in {numref}`l3_adjusted_standard_deviation_error`. ```{table} CDL example description of **adjusted_standard_deviation_error** variable :name: l3_adjusted_standard_deviation_error | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `adjusted_standard_deviation_error` | Total error standard deviation estimate derived from SSES and adjustment method|K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l3_adjusted_standard_deviation_error !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]adjusted_standard_deviation_error[(,:]'| sed 's/[[:space:]]//' ``` (__l3_bias_to_reference_sst)= ### `bias_to_reference_sst` **Mandatory for adjusted type files.** This quantity represents the local value of the adjustment to the reference. The variable `bias_to_reference_sst` shall be included with the format requirements shown in {numref}`l3_bias_to_reference_sst`. ```{table} CDL example description of **bias_to_reference_sst** variable :name: l3_bias_to_reference_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `bias_to_reference_sst` | Bias error derived from comparison with the reference|K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l3_bias_to_reference_sst !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]bias_to_reference_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l3_standard_deviation_to_reference_sst)= ### `standard_deviation_to_reference_sst` **Mandatory for adjusted type files.** This quantity represents the local error standard deviation resulting from the bias estimation method. The variable `standard_deviation_to_reference_sst` shall be included with the format requirements shown in {numref}`l3_standard_deviation_to_reference_sst`. ```{table} CDL example description of **standard_deviation_to_reference_sst** variable :name: l3_standard_deviation_to_reference_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `standard_deviation_to_reference_sst` | Error standard deviation resulting from the bias estimation method|K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l3_standard_deviation_to_reference_sst !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]standard_deviation_to_reference_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l3_source_of_sst)= ### `source_of_sst` **Mandatory and only applicable to super-collated (L3S) type files.** This variable represents the source(s) of SST data when merging the values from different input datasets. When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the `source` attribute of the `sea_surface_temperature` variable. For multiple sources, the GDS-{{gds_version}} requires the following: - The variable in question should contain an attribute called `flag_meanings` and another one called `flag_values`. The `flag_values` attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the comma-separated text strings in the `flag_meanings` attribute. - These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in {numref}`product_codes`. In a super-collated file (L3S), the variable `source_of_sst` shall be included with the format requirements shown in {numref}`l3_source_of_sst`. ```{table} CDL example description of **source_of_sst** variable :name: l3_source_of_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `source_of_sst` | Origin of the SST at pixel level| code | ``` ```{code-cell} :tags: [remove-input] :name: l3_source_of_sst !ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]source_of_sst[(,:]'| sed 's/[[:space:]]//' ``` ## Sample GHRSST L3 file (CDL header) A complete CDL description of a L3S dataset is given below. ```{code-cell} :tags: [remove-input] :name: l3s_dump !ncdump -h samples/20240101000000-IFR-L3S_GHRSST-SSTfnd-ODYSSEA-GLOB_010-v02.2-fv01.0.nc ``` ## Best Practices (l2_remapping_best_practice)= ### Remapping Level 2 Data to a Fixed Grid The remapping procedure consists in remapping the original L2P in swath projection onto a fixed grid. This remapping should preserve the traceability of the SST at pixel level and keep the best quality data. If the original and final grid resolutions are similar, the nearest pixel remapping should be adopted. To do so, either a “source to target” or a “target to source” approach may be used. The latter, target to source, which consists in scanning the target grid points to find the nearest pixel in the source, is recommended since it avoids creating holes in the remapped field. If the original grid resolution is finer than the output grid, {numref}`regridding1` an averaging procedure can be adopted. For these cases the best practice is to average the values of all pixels which overlap the product cell entirely and which have a L2P confidence record `quality_level` value equal to the highest encountered within the cell, to produce a single value. ```{figure} images/regridding1.png --- name: regridding1 --- To illustrate the approach when the L3 product output grid is over-sampled by the L2P input data. All pixels labeled p in the input data are possible contributors to the value for new cell A. ``` The following practices are recommended by the GDS: 1. In the case of a smaller L2P input pixel than the grid cell size, L3 data product cell values are derived from an average of the L2P pixel which completely overlap the product cell and which have a L2P quality record `quality_level` value equal to the highest encountered within the cell, to produce a single value. 2. For input pixels that straddle the boundary between output grid cells, a weighting function may be applied to the input values according to the degree of coverage of the output grid cell and according to the SSES. 3. Only the best quality original data within a grid cell should be averaged to produce the resulting SST value, to preserve the homogeneity of the SST quality (recommendation 1 above). In the case of averaging, the number of contributors can be recorded as well as the sum of the SST values and the sum of the square values of the SST. The SSES and ancillary data (if needed, for instance if there may be more that one SSES couple of values (bias and standard deviation) by quality level) must be averaged accordingly: the `sses_bias` values are averaged similarly as the SST values, the new `sses_standard_deviation` value is the square root of the averaged squared values of the contributing `sses_standard_deviations`. The averaging should account for the nature of the original `l2P_flags`. 4. In the case of a larger pixel than the L3 grid cell size, 2 approaches can be adopted: - The value of the L2P pixel is allocated to the grid cell the closest to the pixel centre. - The output grid cell takes the value of the L2P pixel in which its centre lies. In this case the original latitudes and longitudes of the pixel must be recorded, to be able to detect where the original L2P pixel value has been duplicated. If the original grid resolution is larger than the output grid (e.g., microwave instruments), as illustrated in {numref}`regridding2`, the following practices are recommended by the GDS: ```{figure} images/regridding2.png --- name: regridding2 --- To illustrate the approach when the L3 output grid is under-sampled by the L2P data. Either Grid cell C is assigned the value of pixel p, Or grid cell A is assigned the value of pixel p and grid cell B is assigned the weighted average of p and q provided they both have quality flags with the same rating. ``` (collating_best_practice)= ### Collating Data from the Same Sensor and Platform The collating procedure consists of gathering over a unique grid several orbits or slots (in the case of a geostationary satellite) of the same sensor on the same platform. This process is often known as “binning” the data. The collating procedure merges data with different times of observation. 1) For situations in which the collation is to be done for data collected within the same day, two cases are met in practice: collation of consecutive orbits in the case of data collected from polar orbiting sensors, or the merging of consecutive slots in the case of geostationary satellites. In both cases there may be multiple candidates for a grid cell. a. To collate observations from overlapping orbits of the polar orbiting sensors, the selection procedure should prioritize data first by using the highest available quality data. If multiple observations share the same highest quality, one of two approaches should be taken: either the observation with the minimum satellite zenith angle should be selected, or the observations should be averaged. If the minimum satellite zenith angle approach is taken, the corresponding `sses_bias` and `sses_standard_deviation` should be selected as well. If the averaging approach is followed, the `sses_bias` and `sses_standard_deviation` should be averaged similarly (note that the new `sses_standard_deviation` value is the square root of the averaged squared values of the contributing sses_standard_deviation values). Also in the case of averaging, it is good practice to record the number of observations being averaged, the sum of the SST values, and the sum of the squared SST values. These values can be stored in the `or_number_pixels`, `sum_sst`, and `sum_square_sst` variables listed in Sections and 8 and 9. b. In the case of geostationary data, the selection procedure must prioritize data showing the best quality level, and if equal, data closest to the representative time (central time) of the L3 time window. In the case of geostationary satellites, remapping is not a preliminary step to the collating procedure. 2) If averaging over multiple days, only the best quality original data within a grid cell should be averaged to produce the resulting SST value, to preserve the homogeneity of the SST quality. The number of contributors can be recorded (`or_number_pixels`) as well as the sum of the SST values ( `sum_sst`) and the sum of the square values of the SST (`sum_square_sst`). The SSES values should be averaged accordingly: the `sses_bias` values are averaged in the same manner as the SST values and the new `sses_standard_deviation` value is the square root of the averaged squared values of the contributing `sses_standard_deviation` values. The averaging should preserve the nature of the original `l2P_flags`. (adjustment_best_practice)= ### SST Adjustments Most of individual sensors show regional biases resulting in limitations of the applied algorithms. The objective of the adjustment procedure is to provide a correction to these regional biases by comparison with a “reference sensor”, supposedly free from such biases. A variety of sources can be adopted as references in the adjustment procedure, ranging from AATSR or in situ measurement to using a median of sensors approach. The adopted reference must be recorded in the `adjusted_sea_surface_temperature` variable “reference” attribute. The adjustment procedure includes the following steps: 1. application of the SSES, 2. determination of the bias adjustment to the reference, 3. evaluation of the error of the adjustment procedure ```{note} A skin to subskin conversion may be needed. In that case, please refer to the STVAL recommendations. The type of the SST variables must be recorded in the standard_names of the `sea_surface_temperature` and `adjusted_sea_surface_temperature` variables. The bias adjustment value at pixel and the error of the adjustment procedure must be recorded in the corresponding variables (mandatory). ``` (supercollating_best_practice)= ### Super-Collating Data from Multiple Sensors and Platforms The building of a super-collated file takes place by merging adjusted collated L3 files from various sensors over the same grid and over the same time window. There is one input candidate file (and hence one candidate observation) per sensor. There may be multiple candidates for a given grid cell originating from different sensors. To make the selection from among the candidates, a “decision tree” or selection hierarchy should be established a priori. This hierarchy depends on the objective of the super-collation procedure, and may be quite different for a moderate resolution (10km) super-collated over 24h aiming to feed a foundation SST analysis and for a high resolution (2km) hourly subskin SST super-collated aiming to feed a diurnal warming analysis, for example. Because the hierarchy must be established based on the intended use of the super-collated dataset that results, it is out of the scope of this document to define any single hierarchy. However, the adopted hierarchy must be described in the `comment` attribute of the `adjusted_sea_surface_temperature` variable. In addition, it is mandatory to provide the source of the SST (`source_of_sst`) at the grid cell level. _sources/l2p.md0000664000175000017500000020256414744701353014134 0ustar jfpiollejfpiolle--- jupytext: formats: md:myst text_representation: extension: .md format_name: myst --- (l2p)= # Level 2 Pre-processed (L2P) Product Specification ## Overview description of the GHRSST L2P data product The GHRSST Level-2 Pre-processed (L2P) products are the basic building blocks from which all other GHRSST SST data products can be derived. L2P data products should ideally be made available within the GHRSST R/GTS framework to the user community in real time within 3 hours after the reception of data at the satellite. L2P products include SST data as delivered by a data provider in their native format (swath for polar orbiting satellite), together with a number of ancillary fields that simplify interpretation and application of the SST data. The main difference between input L2 SST data file and the output GHRSST L2P data file is that additional confidence data and sensor specific error estimates for each pixel value are included and the original SST data files are reformatted into the L2P specification. No adjustments to the input L2 SST measurements are allowed but instead, sensor specific error statistics are used to provide bias error and standard deviation estimates. A user wishing to correct L2P SST data can apply these estimates to the SST values directly. Full orbit input data files may be split into ascending and descending files or smaller granules and a unique L2P output may be generated for each file. The common format of L2P products allows data users to code with the security so that as new satellite derived SST data sets are brought on-line, very minimal code changes are required to make full use of new L2P data. Time previously spent on coding different i/o routines for each satellite data set can now be spent applying the data to various applications and societal benefits instead. The GHRSST Science Team agreed at *the 6th GHRSST Science Team Meeting, Met Office, Exeter, United Kingdom, May 14th – 20th 2005*, 6 mandatory fields form the core data content of a GHRSST L2P data file. These fields will be known as **L2P ‘core’ (L2Pcore)** fields. In addition to global attributes and geo-location and time information, GHRSST producers must provide the following L2Pcore fields within an L2P file: - Sea Surface Temperature data (`sea_surface_temperature`) - Time differences of SST measurements from a reference time (`sst_dtime`) - SST Sensor Specific Error Statistic (SSES) measurement bias estimate (`sses_bias`) - SSES measurement standard deviation estimate (`sses_standard_deviation`) - Flags specific to each L2P data set that help users interpret data (`l2p_flags`) - A quality level for each measurement (`quality_level`) In addition there are a number of auxiliary fields (**L2Paux**) that must be provided before the L2P data product is admitted into the GHRSST R/GTS: - the difference between satellite SST measurements and a defined reference climatology of SST (`dt_analysis`) - An estimate of surface wind speed (`wind_speed`) - An estimate of sea ice fraction (`sea_ice_fraction`) - An estimate of atmospheric aerosol (as an aerosol dynamic indicator, `aerosol_dyanamic_indicator`) When an L2P file contains all L2Pcore and L2Paux fields together, it will be called a **full-L2P** file. Only full L2P data files should be registered into the GHRSST R/G TS central catalogue. These distinctions will assist in the data management of the GHRSST GDS-{{gds_version}}. Missing L2Paux fields not provided by a producer may be added by a GHRSST distributor (DAC), if different from the producer, with prior arrangement. In this case data required the L2Paux files will be procured, checked for quality and interpolated or processed according to the GDS-{{gds_version}} specification by the DAC. Optional experimental fields may be used by producers to provide additional information at their discretion. It may be necessary to use an additional netCDF coordinate variable when including experimental fields. GDS-{{gds_version}} L2P data products are configured as shown in the table {numref}`l2p_content_summary`, which can be used to locate appropriate information in this document. ```{table} Summary description of the contents of a GHRSST L2P data product :name: l2p_content_summary | netCDF File Contents | Description | |----------------------|-----------------------------------------------------------------------------------------------------------| | **Coordinate variables** | Information to permit locating data on non-orthogonal grids, as defined in {numref}`coordinate_variables` | | **Data record variables** | Core and auxiliary variables as defined in {numref}`l2p_records` | | **Global Attributes** | A collection of required global attributes describing general characteristics of the file, as defined in section {numref}`global_attributes` | ``` (l2p_records)= ## L2P data record format specification The {numref}`l2p_variables` provides an overview of the GHRSST L2P product pixel data record that should be created for each input L2 SST measurement contained within a L2P file. In the following sections, each variable within the L2P data file is described in detail. ```{table} Summary description of GHRSST L2P data records :name: l2p_variables :class: l2p-variables-css | Variable Name | Description | Units | Storage type | |-----------------------|------------------------|--------|-----| | [sea_surface_temperature](__l2p_sea_surface_temperature) | SST measurement values from input L2 satellite data set. | K (kelvin) | short | | [sst_dtime](__l2p_sst_dtime) | The deviation in time of SST measurement from reference time | s (second)| short | | [sses_bias](__l2p_sses_bias) | Sensor Specific Error Statistic (SSES) bias error | K (kelvin)| byte | | [sses_standard_deviation](__l2p_sses_standard_deviation) | Sensor Specific Error Statistic (SSES) standard deviation uncertainty | K (kelvin)| byte | | [dt_analysis](__l2p_dt_analysis) | The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period | K (kelvin)| byte or short| | [wind_speed](__l2p_wind_speed) | Closest (in time) 10 m surface wind speed from satellite or analysis | m s-1 | byte | | [wind_speed_dtime_from_sst](__l2p_wind_speed_dtime_from_sst) | Time difference of `wind_speed` data from input L2 SST measurement specified in hours.| h (hour) | byte | | [source_of_wind_speed](__l2p_source_of_wind_speed) | Source(s) of `wind_speed` data. Mandatory when multiple sources used. | Code| byte | | [sea_ice_fraction](__l2p_sea_ice_fraction) | Closest (in time) sea ice fraction from satellite or analysis | 1 | byte | | [sea_ice_fraction_dtime_from_sst](__l2p_sea_ice_fraction_dtime_from_sst) | Time difference of `sea_ice_fraction` data from input L2 SST measurement specified in hours| h (hour)| byte | | [source_of_sea_ice_fraction](__l2p_source_of_sea_ice_fraction) | Source(s) of `sea_ice_fraction` data | code | byte | | [aerosol_dynamic_indicator](__l2p_aerosol_dynamic_indicator) | Atmospheric aerosol indicator | | byte | | [adi_dtime_from_sst](__l2p_adi_dtime_from_sst) | Time difference between the `aerosol_dynamic_indicator` value and SST measurement | h (hour) | byte | | [source_of_adi](__l2p_source_of_adi) | Source(s) of `aerosol_dynamic_indicator` data | code | byte | | [l2p_flags](__l2p_l2p_flags) | Data flag values | mask of bits | short | | [quality_level](__l2p_quality_level) | Overall indication of L2P data quality | enum | byte | | [satellite_zenith_angle](__l2p_satellite_zenith_angle) | Calculated satellite zenith angle (measured at the Earth's surface between the satellite and the zenith)| angular_degree | byte or short| | [solar_zenith_angle](__l2p_solar_zenith_angle) | Calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth's surface)| degree | byte | | [surface_solar_irradiance](__l2p_surface_solar_irradiance) | Near contemporaneous surface solar irradiance| W m-2| byte | | [ssi_dtime_from_sst](__l2p_ssi_dtime_from_sst) | Time difference between the `surface_solar_irradiance` value and SST measurement in hours | h (hour)| byte | | [source_of_ssi](__l2p_source_of_ssi) | Source(s) of `surface_solar_irradiance` data | code | byte | | [other fields](__l2p_optional_fields) | Optional/experimental fields defined by data provider | | | ``` (__l2p_sea_surface_temperature)= ### `sea_surface_temperature` The variable `sea_surface_temperature` contains the native unmodified L2 SST of the input data file. L2 SST data are not adjusted in any manner and are identical to the input data set. The `sea_surface_temperature` variable shall be included in a L2P product with the format requirements shown in table {numref}`l2p_sea_surface_temperature`. ```{table} CDL example description of **sea_surface_temperature** variable :name: l2p_sea_surface_temperature | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `sea_surface_temperature` | Pixel sea surface temperature value | K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l2p_sea_surface_temperature !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_surface_temperature[(,:]'| sed 's/[[:space:]]//' ``` The standard_name attribute should be CF-1.7 or later compliant[^footnote1] as described in table {numref}`sst_standard_names`: ```{table} GHRSST short SST names and CF-1.7 standard names for sea_surface_temperature :name: sst_standard_names | GHRSST name | CF-1.7 standard name definitions | |-------------|---------------------------------------| | SSTint | `sea_surface_temperature` | | SSTskin | `sea_surface_skin_temperature` | | | SSTsubskin | `sea_surface_subskin_temperature` | | SSTfnd | `sea_surface_foundation_temperature` | | SSTdepth | `sea_water_temperature` | ``` ````{note} for `SSTdepth`, the attribute `depth` should be used to indicate the depth for which the SST data are valid e.g.: ``` sea_surface_temperature:standard_name="sea_water_temperature"; sea_surface_temperature:units = "K" ; sea_surface_temperature:depth = "1 metre" ; ``` ```` (__l2p_sst_dtime)= ### `sst_dtime` The deviation in time of SST measurement from reference time stored in the netCDF coordinate variable `time` (defined as the start time of granule for L2P). Minimum resolution should be one second. The `sst_dtime` variable shall be included in a L2P product with the format requirements shown in table {numref}`l2p_sst_dtime`. ```{table} CDL example description of **sst\_dtime** variable :name: l2p_sst_dtime | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `sst_dtime` | Deviation from reference time stored in the coordinate variable, `time` | s (seconds) | ``` ```{code-cell} :tags: [remove-input] :name: l2p_sst_dtime !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sst_dtime[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_sses_bias)= ### `sses_bias` Providing uncertainty estimates for each SST measurement is one of the key user requirements for GHRSST L2P SST data products. Uncertainty estimates allow users to select the accuracy level suitable for their application and to make optimum use of the SST observations (e.g. in data assimilation). The uncertainties associated with each observation in a data stream are provided as **Sensor Specific Error Statistic (SSES)**. The SSES are based on understanding the errors associated with the in-flight performance of an individual satellite instrument for the retrieval of SST from the measured radiances. The SSES are provided as a **mean bias error** and its associated **standard deviation** (in variable `sses_standard_deviation`, see {numref}`__l2p_sses_standard_deviation`). There are a variety of methods for determining SSES as they depend on the specific characteristics of each satellite instrument. Consequently, the L2P provider can define their own scheme for producing SSES that is tailored to their specific dataset. However, the SSES scheme must conform to a set of agreed SSES common principles. The SSES common principles are maintained on the [GHRSST website](https://www.ghrsst.org/resources/single-sensor-error-statistic-sses/), and have been approved by the GHRSST Science Team. The L2P provider must provide documentation that summarizes the theoretical basis of their SSES scheme, its implementation, any recommendations for users, and its conformance to the agreed SSES common principles. The variable `sses_bias` is used to store SSES bias estimates and shall be included with the L2P format requirements shown in {numref}`l2p_sses_bias`. Data producers are reminded to choose appropriate `scale_factor` and `add_offset` attributes for their data, and to strive for `scale_factor` as close to 0.01 as possible without “oversaturating” the values. ```{table} CDL example description of **sses_bias** variable :name: l2p_sses_bias | **Storage type** | **Name** | **Description** | **Unit** | |------------------|--------------|----------------------------------|----------| | byte | sses_bias | SSES bias estimate | K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l2p_sses_bias !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sses_bias[(,:]' | sed 's/[[:space:]]//' ``` (__l2p_sses_standard_deviation)= ### `sses_standard_deviation` **Sensor Specific Error Statistic (SSES) standard deviation** estimates are generated by the L2P data provider and are specific to a particular satellite instrument, and must conform to the SSES common principles. See {numref}`__l2p_sses_bias` for the general description of SSES concept and associated variables. The variable `sses_standard_deviation` shall be included with the format requirements shown in {numref}`l2p_sses_standard_deviation`. Data producers are reminded to choose appropriate `scale_factors` and `add_offsets` for their data, and to strive for `scale_factors` as close to 0.01 as possible without “oversaturating” the values. ```{table} CDL example description of **sses_standard_deviation** variable :name: l2p_sses_standard_deviation | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | sses_standard_deviation | SSES standard deviation. | K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l2p_sses_standard_deviation !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sses_standard_deviation[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_dt_analysis)= ### `dt_analysis` The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period. If storage as byte does not allow the provider to offer the full precision required for this field, storage as a short is optionally permitted though byte is preferred. The L2P variable `dt_analysis` is the temperature difference between an input L2 SST measurement and a reference SST L4 analysis data set. `dt_analysis` may be used to indicate potential areas of diurnal variability or gross outliers in the L2 input SST measurement data set by looking for large deviations from the previous analysis SST data. Note that `dt_analysis` is an indicator field and the temperature anomalies may be difficult to interpret in regions of high SST gradients. Furthermore, interpretation requires a good understanding of the strengths and weaknesses (e.g. space and time de-correlations) of the chosen reference L4 analysis system. `dt_analysis` shall be derived using: ```{math} :label: eq_dt_analysis dt\_analysis = SST_{input} – L4_{SST} ``` Where SSTinput is the input satellite L2 measurement and L4 SST is a previous day analysis from a GHRSST L4 System selected by the data provider. The GHRSST L4 analysis chosen for a given L2P data set variable should be consistent for all L2P products as far as practically possible. If a previous analysis SSTfnd data file is not available for use in {eq}`eq_dt_analysis`, then a mean reference SST or climatology should be used in its place as defined in {numref}`l2p_dt_analysis_code`. ```{table} Reference SST data sets for use in dt_analysis computation :name: l2p_dt_analysis_code | Name | Description | Reference | |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------| | Use code from L4 analysis | The mean SSTfnd computed for a n-1 day period. This product is computed from data provider SSTfnd data products in real time each day | https://www.ghrsst.org/ghrsst-data-services/ghrsst-catalogue/ | | GMPE_GLOBAL | Daily, 25 km median average SST and sea ice product created using 10 operational SST analysis products from operational centres around the world | https://ghrsst-pp.metoffice.gov.uk/ostia-website/gmpe-monitoring.html | ``` The `dt_analysis` value shall be inserted into the `dt_analysis` field of the L2P product for the pixel in question as described {numref}`l2p_dt_analysis`. ```{table} CDL example description of **dt_analysis** variable :name: l2p_dt_analysis | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte or short | dt_analysis | Deviation from previous day (T-1) L4 SSTfnd analysis as defined in the {numref}`l2p_dt_analysis_code`. If no analysis is available, the reference mean SST climatology should be used| K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l2p_dt_analysis !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]dt_analysis[(,:]'| sed 's/[[:space:]]//' ``` ```{note} The `reference` variable attribute should be used to specify the analysis or climatology used to compute `dt_analysis` as shown in the example above following the guidelines in {numref}`l2p_dt_analysis_code`. ``` (__l2p_wind_speed)= ### `wind_speed` The L2P variable `wind_speed` contains a best estimate of the **10m surface wind speed, ideally at the time of SST data acquisition** (although this is rarely possible). Wind speed measurements are required within the GDS as an indicator of the turbulent state of the air sea interface to interpret the relationship between satellite and subsurface SST data and assess the severity of any skin SST temperature deviation, thermal stratification and for use in diurnal variability adjustment schemes. At low wind speeds, especially in clear sky conditions, stronger diurnal variability is expected leading to higher surface layer temperature gradients and the potential for significant de-coupling of the skin/sub-skin SST from the SST at depth. Ideally a near contemporaneous wind speed measurement from satellite sensors should be used but this is impossible for all sensors due to the limited number of satellite wind speed sensors available. As a surrogate for a measured wind speed value, analysis product estimates (e.g., from numerical weather prediction models) may be used as an indication of the surface wind speed. The GDS specifies the following rules: > Simultaneous microwave 10m wind speed measurements obtained from the same > instrument providing the SST measurement shall be used when available to set the > L2P confidence data variable `wind_speed`. > In the absence of a simultaneous surface wind speed measurement, an analysis > product estimated 10m surface wind speed shall be used to set the L2P variable > `wind_speed`. The difference in time expressed in hours between the time of SST measurement and the time of wind speed data should be entered into the L2P confidence data variable `wind_speed_dtime_from_sst` as described in {numref}`__l2p_wind_speed_dtime_from_sst`. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the wind speeds have a single time value, as in the case of an analysis or model that gives the wind speeds at an instant in time, then the `wind_speed_dtime_from_sst` variable is not needed and instead a variable level attribute named `time_offset` is used. The attribute `time_offset` should store the difference in hours between the `wind_speed` and the reference time, stored in the variable `time`. If a single source of data is used in the L2P variable `wind_speed` (recommended), the L2P variable `source_of_wind_speed` is not required and a `source` variable attribute of `wind_speed` is sufficient. In that case, it shall be a single source text string defined by the data provider using the text string naming best practice given in {numref}`product_codes`. If multiple sources of data are used, source information should be indicated in the L2P variable `source_of_wind_speed` as defined by the data provider and as described in detail in {numref}`__l2p_source_of_wind_speed`, and the `source` variable attribute of `wind_speed` shall have the value `source_of_wind_speed`. In addition, the units of all sources used in the file shall be identical. The GDS L2P variable `wind_speed` shall be included in L2P products with the format requirements shown in the {numref}`l2p_wind_speed`. ```{table} CDL example description of **wind_speed** variable :name: l2p_wind_speed | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | wind_speed | Surface wind speed at 10m height. Resolution should be no less than 1 m s-1 | m s-1 | ``` ```{code-cell} :tags: [remove-input] :name: l2p_wind_speed !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]wind_speed[(,:]'| sed 's/[[:space:]]//' ``` A single source of wind data is shown in this example which is reported as `wind_speed:source = "ECMWF_Anaylsis_V2"` the code has been defined by the data provider using the ancillary data naming rules given in {numref}`product_codes`. Since all of the wind speeds have the same time, the attribute `time_offset` is used instead of the variable `wind_speed_dtime_from_sst`. (__l2p_wind_speed_dtime_from_sst)= ### `wind_speed_dtime_from_sst` The variable `wind_speed_dtime_from_sst` reports the time difference between wind speed data and SST measurement in hours. The variable `wind_speed_dtime_from_sst` shall be included with the format requirements shown in {numref}`l2p_wind_speed_dtime_from_sst`. In the case of an analysis field, the central (mean) time of an integrated value should be used. If all values are the same, this variable is not required. Instead, use the variable level attribute named `time_offset` with the variable `wind_speed`. ```{table} CDL example description of **wind_speed_dtime_from_sst** variable :name: l2p_wind_speed_dtime_from_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `wind_speed_dtime_from_sst` | This variable reports the time difference of wind speed measurement from SST measurement in hours. | h (hour) | ``` ```{code-cell} :tags: [remove-input] :name: l2p_wind_speed_dtime_from_sst !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]wind_speed_dtime_from_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_source_of_wind_speed)= ### `source_of_wind_speed` The source of data used to set the L2P ancillary data variable `wind_speed` shall be indicated in the L2P variable `source_of_wind_speed` when more than one source of wind speed data is used in the L2P product. When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the `source` attribute of the `wind_speed` variable. If the values in that single source all have the same time, then a variable attribute `time_offset` set as the difference time in hours is considered sufficient and the variable `wind_speed_dtime_from_sst` is not required. For multiple sources, the GDS-{{gds_version}} requires the following: - The variable in question should contain an attribute called `flag_meanings` and another one called `flag_values`. The `flag_values` attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the comma-separated text strings in the `flag_meanings` attribute. - These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in {numref}`product_codes`. - instead of using a `_FillValue` attribute and value for missing data, it is recommended to set missing pixel values to **0** and add the corresponding **no_data** meaning in `flag_meanings` attribute. The variable `source_of_wind_speed` shall conform to the format requirements shown in the {numref}`l2p_source_of_wind_speed`. ```{table} CDL example description of **source_of_wind_speed** variable :name: l2p_source_of_wind_speed | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `source_of_wind_speed` | Sources of `wind_speed` values. | code | ``` ```{code-cell} :tags: [remove-input] :name: l2p_source_of_wind_speed !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_wind_speed[(,:]'| sed 's/[[:space:]]//' ``` In this example, `flag_meanings` and `flag_values` contain strings and numeric codes provided by the data provider according to the best practices specified in {numref}`l2p_source_of_wind_speed`. (__l2p_sea_ice_fraction)= ### `sea_ice_fraction` Some SST data are contaminated in part or wholly by sea ice and the L2P variable `sea_ice_fraction` is used to quantify the fraction of an area contaminated with sea ice, ranging from 0 to 1. Some input SST data streams provide a flag to indicate that the SST measurement is contaminated by sea ice (e.g., passive microwave radiometers such as AMSR-E). If an input data set pixel fractional sea ice estimate exists, this should be used to in the L2P variable `sea_ice_fraction` as described in the table {numref}`l2p_sea_ice_fraction`. Best practice suggests that one should approach the issue in the following way. If an input data set pixel sea ice flag does not exist, and the pixel is located in or close to a region that may be ice contaminated, a reference sea ice data set should be used to determine the value of the L2P variable `sea_ice_fraction`. If an input data set pixel sea ice flag exists (i.e. indicating sea ice but not the fractional amount of coverage), this should be used to set the L2P variable `sea_ice_fraction` to 1. If the SST input data set includes a sea ice flag in the data stream, bit 3 of the L2P confidence data variable `l2p_flags` should be set for this pixel as described in {numref}`__l2p_l2p_flags`. The difference in time expressed in hours between the time of SST measurement and the time of sea ice fraction measurement should be entered into the L2P variable `sea_ice_fraction_dtime_from_sst` as described in in {numref}`__l2p_sea_ice_fraction_dtime_from_sst`. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all ice observations have a single time value, as in the case of an analysis or model that gives the sea ice values at an instant in time, then the `sea_ice_fraction_dtime_from_sst` variable is not needed and instead a variable attribute named `time_offset` is used. The attribute `time_offset` should store the difference in hours between the `sea_ice_fraction` and the reference time, stored in the variable `time`. If a single source of data is used in the L2P variable `sea_ice_fraction`, the L2P variable `source_of_sea_ice_fraction` is not required and instead the `source` variable attribute value of `sea_ice_fraction` is sufficient. It shall be a single source text string defined by the data provider using the text string naming best practice given in {numref}`product_codes`. If multiple sources of data are used, source information should be indicated in the L2P variable `source_of_sea_ice_fraction` as defined by the data provider and as described in detail in {numref}`__l2p_source_of_sea_ice_fraction`, and the `source` variable attribute of `sea_ice_fraction` shall have the value `source_of_sea_ice_fraction`. In addition, the units of all sources used in the file shall be identical. The variable attribute `sea_ice_treatment` shall specify how the sea ice information has been treated by the data provider. Valid options are: *"Use unmodified (one source)"*, *"use unmodified (multiple ice sources)”*, or *“modified using onboard sensors"*. The variable `sea_ice_fraction` will be included with the format requirements shown in {numref}`l2p_sea_ice_fraction`. ```{table} CDL example description of **sea_ice_fraction** variable :name: l2p_sea_ice_fraction | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `sea_ice_fraction` | fractional of sea ice contamination in a given pixel. Ranges from 0 to 1. | 1 (unitless) | ``` ```{code-cell} :tags: [remove-input] :name: l2p_sea_ice_fraction !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_ice_fraction[(,:]'| sed 's/[[:space:]]//' ``` A single source of sea ice fraction data is shown in this example which is reported as `sea_ice_fraction:source = "REMSS_AMSRE_V5"` following the ancillary data naming conventions specified in {numref}`product_codes`. Since all of ice values have the same time, the attribute `time_offset` is used instead of the variable `sea_ice_fraction_dtime_from_sst`. (__l2p_sea_ice_fraction_dtime_from_sst)= ### `sea_ice_fraction_dtime_from_sst` The variable `sea_ice_fraction_dtime_from_sst` reports the time difference between sea ice fraction data from SST measurement in hours. This variable is mandatory when multiple sources of `sea_ice_fraction` are used. If only one source is used, simply set a variable attribute `time_offset` in `sea_ice_fraction` variable, as the difference time in hours. The variable `sea_ice_fraction_dtime_from_sst` shall be included with the format requirements shown {numref}`l2p_sea_ice_fraction_dtime_from_sst`. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the values are the same, this variable is not required. Instead, use the variable level attribute named `time_offset` with the variable `sea_ice_fraction`. The attribute `time_offset` should store the difference in hours between the sea ice analysis time and the reference time, stored in the variable `time`. ```{table} CDL example description of **sea_ice_fraction_dtime_from_sst** variable :name: l2p_sea_ice_fraction_dtime_from_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `wind_speed_dtime_from_sst` | This variable reports the time difference between sea ice fraction data from SST measurement in hours. | hour | ``` ```{code-cell} :tags: [remove-input] :name: l2p_sea_ice_fraction_dtime_from_sst !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_ice_fraction_dtime_from_sst[(,:]'| sed 's/[[:space:]]//' ``` This variable is mandatory when multiple sources for `sea_ice_fraction` are used. If only one source is used, instead simply set a variable attribute `sea_ice_fraction:sea_ice_fraction_dtime_from_sst = \`. (__l2p_source_of_sea_ice_fraction)= ### `source_of_sea_ice_fraction` The source of data used to set the L2P ancillary data variable `sea_ice_fraction` shall be indicated in the L2P variable `source_of_sea_ice_fraction` when more than one source of sea ice fraction data is used in the L2P product. When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the source attribute of the `sea_ice_fraction` variable. For multiple sources, the GDS-{{gds_version}} requires the following: - The variable in question should contain an attribute called `flag_meanings` and another one called `flag_values`. The `flag_values` attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the comma-separated text strings in the `flag_meanings` attribute. - These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in {numref}`product_codes`. - instead of using a `_FillValue` attribute and value for missing data, it is recommended to set missing pixel values to **0** and add the corresponding **no_data** meaning in `flag_meanings` attribute. - The variable `source_of_sea_ice_fraction` shall conform to the format requirements shown in {numref}`l2p_source_of_sea_ice_fraction`. ```{table} CDL example description of **source_of_sea_ice_fraction** variable :name: l2p_source_of_sea_ice_fraction | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `source_of_sea_ice_fraction` | Source(s) of sea ice values | None | ``` ```{code-cell} :tags: [remove-input] :name: l2p_source_of_sea_ice_fraction !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_sea_ice_fraction[(,:]'| sed 's/[[:space:]]//' ``` In this example, `flag_meanings` and `flag_values` contain strings and numeric codes provided by the data provider according to the best practices specified in {numref}`product_codes`. (__l2p_aerosol_dynamic_indicator)= ### `aerosol_dynamic_indicator` **Mandatory (only for infrared instruments).** The L2P variable `aerosol_dynamic_indicator` contains an indicator of potential atmospheric aerosol contamination of infrared satellite SST data. Infrared-absorbing atmospheric aerosols are a major source of error in satellite-derived sea surface temperature retrievals. Atmospheric aerosol, such as Saharan dust outbreaks, volcanic eruptions or from coastal mega cities causes errors in the atmospheric correction of top of the atmosphere radiances when retrieving SST from infrared and visible band data sets. A systematic bias in the tropical North Atlantic Ocean and Arabian Sea due to desert dust outflows in those regions is apparent. An aerosol indicator (e.g., derived from satellite measurements or models) value is assigned to the L2P variable `aerosol_dynamic_indicator` for each corresponding infrared retrieved SST measurement pixel using data chosen by the data provider to indicate aerosol contamination. The aerosol indicator data nearest in space and time to the input pixel SST value should be used. In the case of microwave SST measurements there is no requirement to include the `aerosol_dynamic_indicator` L2P variable as microwave SST retrievals are not affected by atmospheric aerosols. However, microwave SST data providers may include `aerosol_dynamic_indicator` in an L2P product. If a single source of data is used in the L2P variable `aerosol_dynamic_indicator`, the L2P variable `source_of_adi` is not required and instead the `source` variable attribute value in `aerosol_dynamic_indicator` is sufficient. It shall be a single source text string defined by the data provider using the text string naming best practice given in {numref}`product_codes`. If all the times have the same value, then using a variable attribute `time_offset` with variable `aerosol_dynamic_indicator` is sufficient and the variable `adi_dtime_from_sst` is not required. If multiple sources of ADI information are used then, the `source` variable attribute of `aerosol_dynamic_indicator` variable shall have the value `source_of_adi`. In addition, the units of all sources used in the file shall be identical. The difference in time expressed in hours between the time of SST measurement and the time of aerosol indicator data should be entered into the L2P variable `adi_dtime_from_sst` as described in {numref}`__l2p_adi_dtime_from_sst`. In the case of an analysis field, this should be the central (mean) time of an integrated value. If the variable `aerosol_dynamic_indicator` is provided in an L2P product, it shall be included with the format requirements shown in the {numref}`l2p_aerosol_dynamic_indicator`. ```{table} CDL example description of **aerosol_dynamic_indicator** variable :name: l2p_aerosol_dynamic_indicator | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `aerosol_dynamic_indicator` | Indicator of potential aerosol contamination of infrared satellite data | Provider defined | ``` ```{code-cell} :tags: [remove-input] :name: l2p_aerosol_dynamic_indicator !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]aerosol_dynamic_indicator[(,:]'| sed 's/[[:space:]]//' ``` A single source of `aerosol_dynamic_indicator` has been used in this example indicated using the `aerosol_dynamic_indicator:source` and are defined by the data provider using the ancillary data naming best practice given in {numref}`product_codes`. Since all of the values have the same time, the attribute `time_offset` is used instead of the variable `aerosol_sst_dtime_from_sst` to indicate the offset in hours from the reference variable `sst_dtime`. (__l2p_adi_dtime_from_sst)= ### `adi_dtime_from_sst` The variable adi_dtime_from_sst reports the time difference between aerosol indicator data from input L2 SST measurement in hours. The variable `adi_dtime_from_sst` shall be included in L2P products with the format requirements shown in the {numref}`l2p_adi_dtime_from_sst`. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the values are the same, this variable is not required. Instead, use the variable level attribute named `time_offset` with the variable `aerosol_dynamic_indicator`. ```{table} CDL example description of **adi_dtime_from_sst** variable :name: l2p_adi_dtime_from_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `adi_dtime_from_sst` | Time difference of aerosol dynamic indicator data from SST measurement in hours | hour | ``` ```{code-cell} :tags: [remove-input] :name: l2p_adi_dtime_from_sst !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_ice_fraction_dtime_from_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_source_of_adi)= ### `source_of_adi` The source of data used to set the L2P ancillary data variable `aerosol_dynamic_indicator` shall be indicated in the L2P variable `source_of_adi` when more than one source of SSI data is used in the L2P product. When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the sources attribute of the `aerosol_dynamic_indicator` variable. For multiple sources, The variable in question should contain an attribute called `flag_meanings` and another one called `flag_values`. The `flag_values` attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the `flag_meanings` attribute. These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in {numref}`product_codes`. instead of using a `_FillValue` attribute and value for missing data, it is recommended to set missing pixel values to **0** and add the corresponding **no_data** meaning in `flag_meanings` attribute. The variable `source_of_adi` shall conform to the with the format requirements shown in the {numref}`l2p_source_of_adi`. ```{table} CDL example description of **source_of_adi** variable :name: l2p_source_of_adi | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `source_of_adi` | Sources of aerosol dynamic indicator values | None | ``` ```{code-cell} :tags: [remove-input] :name: l2p_source_of_adi !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_adi[(,:]'| sed 's/[[:space:]]//' ``` In this example, `flag_meanings` and `flag_values` contain strings and numeric codes provided by the data provider according to the best practices specified in {numref}`product_codes`. (__l2p_l2p_flags)= ### `l2p_flags` **Mandatory.** The GDS-{{gds_version}} L2P variable `l2p_flags` is used to - Specify the type of input SST data (either infrared or passive microwave instrument derived), - Pass through native flags from the input L2 SST data set and - Record any additional information considered important for the user of an L2P data set. The L2P variable `l2p_flags` holds Boolean (single bit) codes detailed in its `flag_meanings` and `flag_masks` attributes, and split into two sections: - The first 6 bits of the L2P variable `l2p_flags` are generic flags that are common to all L2P data files as defined in the {numref}`l2p_flags_bits` - Bits 6-15 are defined by the L2P data provider and are specific to each L2 input data stream ```{table} List of bits composing the **l2P_flags** variable :name: l2p_flags_bits | Bit | Common flags | |------|--------------| | 0 | Set if passive microwave data (not set is assumed to be infrared) | | 1 | Set if over land (not set is assumed to be ocean) | | 2 | Set if pixel is over ice | | 3 | Set if pixel is over a lake (if known) | | 4 | Set if pixel is over a river (if known) | | 5 | Reserved for future data | | 6-15 | Defined by L2 data provider | ``` The `flag_meanings` attribute shall contain a space-separated list of (string with no space) descriptions for each distinct flag value. For descriptions containing multiple words, the words shall be linked by underscores. The `flag_masks` attribute shall contain a comma-separated list of (numeric) mask values that isolate the bit or bits that encode each flag value, whose order matches that of the `flag_meanings` values. It is recommended not to use `_FillValue` attribute as it is prone to misinterpretation of the bit mask. - **Bit 0** of the L2P `l2p_flags` is used to record if an input pixel SST is derived from an infrared satellite sensor or a passive microwave sensor. If an input pixel is derived from a passive microwave sensor, bit 0 of the L2P `l2p_flags` variable should be set to 1. By not setting this flag the pixel is assumed to be from an infrared sensor. - **Bit 1** of the L2P `l2p_flags` variable is used to record if an input pixel is over land or ocean surfaces. If an input pixel is classified as land covered bit 1 of the L2P `l2p_flags` variable should be set to equal 1. By not setting this flag the pixel is assumed to be classified as over ocean. - **Bit 2** of the L2P `l2p_flags` variable is used to record if an input pixel records ice contamination. If an input pixel is classified as ice contaminated bit 2 of the L2P `l2p_flags` variable should be set to 1. - **Bit 3** of the L2P `l2p_flags` variable is used to record if an input pixel contains any part of a lake, as defined by the GHRSST definition of lakes (mask). If an input pixel contains any part of a lake, as defined by the GHRSST definition of lakes (mask), bit 3 of the L2P `l2p_flags` variable should be set to 1. - **Bit 4** of the L2P `l2p_flags` variable is optionally used to record if an input pixel contains any part of a river, as defined by the GHRSST definition of rivers (mask). If an input pixel contains any part of a river, as defined by the GHRSST definition of rivers (mask), bit 4 of the L2P `l2p_flags` variable should be set to 1. Flags or other information provided with the input L2 SST data should be defined and assigned to the `l2p_flags` variable using bits 6-15 of the L2P variable l2p_flags. It is recommended to use single bits for any information, no combination of multiple bits. If that is not possible, then an additional experimental byte field should be used instead. Definitions for bits 6-15, if used, should be given using the variable comment attribute. The L2P variable `l2p_flags` shall be included in GDS-{{gds_version}} L2P data files with the format requirements shown in {numref}`l2p_l2p_flags`. ```{table} CDL example description of **source_of_adi** variable :name: l2p_l2p_flags | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `l2p_flags` | The variable l2p_flags is used to
(a) specify the type of input SST data (either infrared or passive microwave instrument derived),
(b) pass through native flags from the input L2 SST data set and
(c) record any additional information considered important for the user of an L2P data set | None | ``` ```{code-cell} :tags: [remove-input] :name: l2p_source_of_adi !ncdump -h samples/l2p_full_example.nc | grep $'[, \t]l2p_flags[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_quality_level)= ### `quality_level` **Mandatory.** The L2P variable `quality_level` provides an indicator of the overall quality of an SST measurement in an L2P file. The GDS requires the following: The L2P variable `quality_level` shall use an incremental scale from **0 to 5** to provide the user with an indication of the quality of the L2P SST data, reflecting the CEOS QA4EO (Quality Indicator) guidelines. The value **0** shall be used to indicate missing data and the value **1** shall be used to indicate invalid data (e.g. cloud, rain, too close to land - under no conditions use this data). The remaining values from **2-5** are set at the discretion of the L2P provider with the proviso that the value **2** shall be used to indicate the worst quality of usable data and the value **5** shall be used to indicate the best quality usable data. The L2P provider is required to provide a description of the quality levels provided as part of the product documentation. The L2P variable `quality_level` reflects the quality of SST data from a single sensor and does not provide an indication of the relative quality between sensors. The L2P variable `quality_level` shall be included with the format requirements shown in the {numref}`l2p_quality_level`. We recommend not to use the `_FillValue` attribute but rather to use the value **0** to fill in missing data pixels. ```{table} CDL example description of **quality_level** variable :name: l2p_quality_level | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `quality_level` | Overall indicator of SST measurement quality | n/a | ``` ```{code-cell} :tags: [remove-input] :name: l2p_quality_level !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]quality_level[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_satellite_zenith_angle)= ### `satellite_zenith_angle` **Optional.** Sea surface temperature retrievals from satellite instruments degrade as the sensor zenith angle increases. Measurements made with high viewing angles relative to nadir appear to be considerably colder than they are in reality. The L2P variable `satellite_zenith_angle` contains the calculated satellite zenith angle (measured at the Earth's surface between the satellite and the zenith) for the input L2 SST based on the satellite geometry at the time of SST data acquisition. The GDS L2P variable `satellite_zenith_angle` is an optional field that may be provided by a data provider. The satellite zenith angle for each input pixel measurement should be recorded in the L2P variable `satellite_zenith_angle` having a range of 0° to +90°. If the L2P variable `satellite_zenith_angle` is included in a L2P data product it shall conform to the format requirements shown in {numref}`l2p_satellite_zenith_angle`. ```{table} CDL example description of **satellite_zenith_angle** variable :name: l2p_satellite_zenith_angle | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte or short | `satellite_zenith_angle` | Calculated satellite zenith angle (measured at the Earth's surface between the satellite and the local zenith) for the input L2 SST based on the satellite geometry at the time of SST data acquisition.
Ranges from 0 to 90 degrees.| angular_degree | ``` ```{code-cell} :tags: [remove-input] :name: l2p_satellite_zenith_angle !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]satellite_zenith_angle[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_solar_zenith_angle)= ### `solar_zenith_angle` **Optional.** The L2P variable `solar_zenith_angle` contains the calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth's surface) for the input L2 SST based on the satellite geometry at the time of SST data acquisition. Solar zenith angle is a function of time, day number and latitude. The GDS L2P variable `solar_zenith_angle` is an optional field that may be provided by a data provider. The solar zenith angle for each input pixel measurement should be recorded in the L2P variable `solar_zenith_angle` having a range of 0° to 180°. If the L2P variable `solar_zenith_angle` is included in a L2P data product it shall conform to the format requirements shown in {numref}`l2p_solar_zenith_angle`. ```{table} CDL example description of **solar_zenith_angle** variable :name: l2p_solar_zenith_angle | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte or short | `solar_zenith_angle` | Calculated solar zenith angle (measured at the Earth's surface between the sun and the local zenith) for the input SST based on the solar geometry at the time of SST data acquisition.
Ranges from 0 to 180 degrees.| angular_degree | ``` ```{code-cell} :tags: [remove-input] :name: l2p_solar_zenith_angle !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]solar_zenith_angle[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_surface_solar_irradiance)= ### `surface_solar_irradiance` **Optional.** Surface Solar Irradiance (SSI) data were originally required within the GDS 1.6 to assess the magnitude and variability of significant diurnal SST variations, for use in diurnal variability correction schemes, for use in L4 SST analysis procedures and to interpret the relationship between satellite and in situ SST data. In the GDS-{{gds_version}}, it is an optional variable. Ideally a near contemporaneous SSI measurement from satellite sensors should be used but this is impossible for all areas due to the limited number of geostationary satellite sensors available. As a surrogate for a measured SSI value, analysis estimates may be used. Surface solar Irradiance (SSI) data may be assigned to each L2P SST measurement pixel using the variable `surface_solar_irradiance`. An integrated down-welling SSI measurement (e.g., derived from satellite measurements) should be assigned to each SST pixel value using the `surface_solar_irradiance` L2P variable. The SSI measurement nearest in space and time before the input pixel SST value should be used. If no SSI measurement is available, an integrated SSI value derived from an analysis system nearest in space and time to the SST measurement should be used to set the value of `surface_solar_irradiance`. The difference in time expressed in hours between the time of SST measurement and the time of surface solar irradiance data should be entered into the L2P confidence data variable `ssi_dtime_from_sst`. In the case of an analysis field, this should be the central (mean) time of an integrated value. If all of the values have the same time, the attribute `time_offset` is used instead of the variable `ssi_dtime_fraction_dtime_from_sst`. The attribute `time_offset` should store the difference in hours between the `surface_solar_irradiance` and the reference time, stored in the variable `time`. If a single source of data is used in the L2P variable `surface_solar_irradiance`, the L2P variable `source_of_ssi` is not required and instead the `surface_solar_irradiance:source` attribute value is sufficient. It shall be a single source text string defined by the data provider using the text string naming best practice given in {numref}`product_codes`. If multiple sources of data are used, source information should be indicated in the L2P variable `source_of_ssi` as defined by the data provider and as described in detail in {numref}`l2p_surface_solar_irradiance`. Then, the `surface_solar_irradiance:source` attribute shall have the value `source_of_ssi`. The L2P variable `surface_solar_irradiance` may be included by a data provider with the format requirements shown in {numref}`l2p_surface_solar_irradiance`. ```{table} CDL example description of **surface_solar_irradiance** variable :name: l2p_surface_solar_irradiance | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `surface_solar_irradiance` | Near contemporaneous integrated Surface Solar Irradiance (SSI) data. | $W m^{-2}$ | ``` ```{code-cell} :tags: [remove-input] :name: l2p_surface_solar_irradiance !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]surface_solar_irradiance[(,:]'| sed 's/[[:space:]]//' ``` A single source of SSI data is shown in this example which is reported as `surface_solar_irradiance:source = "SSI-MSG_SEVIRI-V1"` The text string has been defined by the data provider using the text string naming best practice given in {numref}`product_codes`. Since all of the SSI values have the same time, the attribute `time_offset` is used instead of the variable `ssi_dtime_from_sst`. (__l2p_ssi_dtime_from_sst)= ### `ssi_dtime_from_sst` **Optional (Mandatory only if multiple observation time for `surface_solar_irradiance` are provided).** The variable `ssi_dtime_from_sst` reports the time difference between SSI data from SST measurement in hours. The variable `ssi_dtime_from_sst` shall be included with the format requirements shown in {numref}`l2p_ssi_dtime_from_sst`. In the case of an analysis field, the central (mean) time of an integrated value should be used. If all of the values are the same, this variable is not required. Instead, use the variable level attribute named `time_offset` with the variable `surface_solar_irradiance`. ```{table} CDL example description of **ssi_dtime_from_sst** variable :name: l2p_ssi_dtime_from_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `ssi_dtime_from_sst` | This variable reports the time difference between SSI data from SST measurement in hours | hour | ``` ```{code-cell} :tags: [remove-input] :name: l2p_ssi_dtime_from_sst !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]ssi_dtime_from_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l2p_source_of_ssi)= ### `source_of_ssi` **Optional (Mandatory only if multiple sources for `surface_solar_irradiance` are provided).** The source of data used to set the L2P ancillary data variable `surface_solar_irradiance` shall be indicated in the L2P variable `source_of_ssi` when more than one source of SSI data is used in the L2P product. When only one source is used, this variable is not needed and the appropriate text string indicating the source is placed in the `source` attribute of the `surface_solar_irradiance` variable. For multiple sources, the variable `source_of_ssi` should contain an attribute called `flag_meanings` and another one called `flag_values`. The `flag_values` attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the `flag_meanings` attribute. These text strings and numeric codes do not need to be unique across different data sets or even ancillary variables, but must be consistent within a given variable and clearly specified within each netCDF variable and its attributes. A best practice for naming the text strings in provided in {numref}`product_codes`. instead of using a `_FillValue` attribute and value for missing data, it is recommended to set missing pixel values to **0** and add the corresponding **no_data** meaning in `flag_meanings` attribute. The variable `source_of_ssi` shall conform to the format requirements shown in the {numref}`l2p_source_of_ssi`. ```{table} CDL example description of **source_of_ssi** variable :name: l2p_source_of_ssi | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | byte | `source_of_ssi` | Sources of surface solar irradiance values | code | ``` ```{code-cell} :tags: [remove-input] :name: l2p_source_of_ssi !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_ssi[(,:]'| sed 's/[[:space:]]//' ``` In this example, `flag_meanings` and `flag_values` contain code data provided by the data provider according to the best practices specified in {numref}`product_codes`. An example of these codes is given in the {numref}`l2p_source_of_ssi_codes`. ```{table} Example text string and numeric codes used to identify the sources of data in surface_solar_irradiance:sources and source_of_ssi :name: l2p_source_of_ssi_codes | Numeric Code | Text String | Sources of surface solar irradiance Description | |----------------|----------------------|--------------------------------------------------| | 0 |no_data |No surface solar irradiance set| | 1 | SSI-MSG_SEVIRI-V1 |SSI from Meteosat Second Generation SEVIRI instrument (EUMETSAT OSI-SAF| | 2 | SSI-NOAA-GOES_E-V1 |GOES_E SSI data from NOAA | | 3 | SSI-NOAA-GOES_W-V1 |GOES_W SSI data from NOAA| | 4 | SSI-ECMWF-V1 |SSI data from European Centre for Medium Range Weather Forecasting| | 5 | SSI-NCEP-V1 |SSI data from NOAA’s National Center for Environmental Prediction| | 6 | SSI-NAVY-NAAPS-V1|SSI data from the US Navy Atmospheric aerosol Prediction system| | 7 | |Spare to be defined as required| ``` (__l2p_optional_fields)= ### Optional experimental L2P variables included by data provider Flexibility of L2P product content is provided through the netCDF API, which allows fully self-describing fields and additional L2P variables may be included by L2P data providers if they are considered relevant for L2P users. The GDS-{{gds_version}} also permits the inclusion of R&D variables (e.g. channel radiance data sets, estimates of Chlorophyll A, fields that facilitate flagging of diurnal variability, etc.) and 32 bytes per pixel are available in total for optional/experimental variables in any combination (i.e., variables can be defined as 32 x byte, 16 x short, 3 x int + 4 x byte, etc). The use of optional/experimental variables provides a limited amount of flexibility within the GDS-{{gds_version}} for regional user requirements while maintaining an overall upper limit on GDS-{{gds_version}} L2P products for data management groups and archive scaling. In exceptional cases a waiver on the 32 byte ceiling can be requested to extend up to 64 bytes per pixel. The GDS-{{gds_version}} issues the following guidance on the inclusion of optional or experimental variables within L2P data products: - The sum total of all experimental variables shall not increase L2P record size by more than **32 bytes** per SST pixel. A **waiver** can be requested for higher amounts up to 64 bytes. - CF-1.7 or later compliance should be maintained for all optional/experimental variables. Where available, a standard_name attribute should be used. - It is permitted to use a provider defined coordinate variable associated with experimental fields but this shall be documented in data provider documentation. - Time difference data (dtime values) should be provided for variables when appropriate. - The source of data should be indicated: in the single source case as a variable attribute; as a dedicated variable when mixed data sources are present. - Use of experimental variables requires clear documentation by the GHRSST producer. They shall provide adequate documentation that describes each variable following the CDL examples provided in this document. - The variable attribute `comment` shall be used to provide a URL link to a full description of each data producer defined variable included in the L2P product. - Experimental L2P variables if present in an L2P product will be included with the minimum format requirements shown in {numref}`l2p_experimental` - Additional global variables may be declared within the L2P product. ```{table} CDL template for data provider defined L2P variables :name: l2p_experimental | Storage type definition | Variable name definition | Description | Unit | |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------|------------------------------|------| | byte | Provide a variable name in lower case using underscore separators e.g. `my_variable` | Provide a description of `my_variable` stating content purpose and units | Units of `my_variable` | ``` ```{code-cell} :tags: [remove-input] :name: l2p_experimental !ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]my_variable[(,:]'| sed 's/[[:space:]]//' ``` ## CDL example L2P dataset The following CDL has been generated for a L2P dataset derived from the VIIRS sensor on NOAA-20 platform (https://doi.org/10.5067/GHV20-2PO28) . It includes a number of optional and experimental variables. **ADD CDL EXAMPLE** [^footnote1]: netCDF Climate and Forecast (CF) Metadata Conventions version 1.7 or later available from http://cfconventions.org_sources/conventions.md0000664000175000017500000000446514707171175016006 0ustar jfpiollejfpiolle# Document Conventions The following sub-sections describe the notation conventions and data storage types that are used throughout this GDS Technical Specification. Implementation projects are expected to adhere to the nomenclature and style of the GDS in their own documentation as much as possible to facilitate international coordination of documentation describing the data products and services within the GHRSST R/GTS framework. ## Use of text types The text styles defined in {numref}`text_styles` are used throughout the GDS. ```{table} Definition of text styles used in the GDS :name: text_styles **Text type**|**Meaning**|**Example** -----|-----|----- Liberation Mono|Denotes a variable name|`dt_analysis` Liberation Mono|Denotes a netCDF attribute name|`gds_version_id` Arial|Denotes regular text.|This is normal text. ``` ## Use of colour in tables The colours defined in {numref}`colour_styles` are used throughout the GDS. ```{table} Storage type definitions used in the GDS :name: colour_styles :class: cstyles-css **Colour**|**Meaning**|**Example** :-----:|:-----:|:-----: Grey|Denotes a table column name|`Variable` Blue|Denotes a mandatory item|`analysed_sst` Violet|Denotes an item mandatory for only certain situations|`dt_analysis` Yellow|Denotes an optional item|experimental_field Green|Denotes grid dimensions|`ni=1024` Pink|Denotes grid variable dimensions|`float lat(nj, ni)` ``` ## Definitions of storage types Computer storage types referred to in the GDS are defined in {numref}`storage_types` and follow those used in netCDF. ```{table} Storage type definitions used in the GDS :name: storage_types **Name**|**Storage Type** :-----:|:-----: byte|8 bit signed integer short|16 bit signed integer int (or long)|32 bit signed integer float|32 bit floating point double|64 bit floating point string|Character string ``` _sources/intro.md0000664000175000017500000000523314705223421014554 0ustar jfpiollejfpiolle# The Recommended GHRSST Data Specification (GDS) Version {{gds_version}} A new generation of integrated Sea Surface Temperature (SST) data products are being provided by the **[Group for High Resolution Sea Surface Temperature (GHRSST)](https://doi.org/10.1175/BAMS-88-8-1197)**. L2 products are provided by a variety of data providers in a common format. L3 and L4 products combine, in near-real time, various SST data products from several different satellite sensors and in situ observations and maintain fine spatial and temporal resolution needed by SST inputs to a variety of ocean and atmosphere applications in the operational and scientific communities. Other GHRSST products provide diagnostic data sets and global multi-product ensemble analysis products. Retrospective reanalysis products are provided in a non-real time critical offline manner. All GHRSST products have a standard format, include uncertainty estimates for each measurement, and are served to the international user community free of charge through a variety of data transport mechanisms and access points that are collectively referred to as the **GHRSST Regional/Global Task Sharing (R/GTS) framework**. The GHRSST Data Specification (GDS) Version {{gds_version}} is a technical specification of GHRSST products. The GHRSST services are described in a separate [Architecture Document (GSA)](https://10.5281/zenodo.4700398). The GDS technical documents are supported by a User Manual. GDS {{gds_version}} represents a consensus opinion of the GHRSST international community on how to optimally combine satellite and in situ SST data streams within the R/GTS. The GDS also provides guidance on how data providers might implement SST processing chains that contribute to the R/GTS. This document first provides an overview of GHRSST followed by detailed technical specifications of the adopted file naming specification and supporting definitions and conventions used throughout GHRSST and the technical specifications for all GHRSST Level 2P, Level 3, Level 4. In addition, the GDS {{gds_version}} Technical Specification provides controlled code tables and best practices for identifying sources of SST and ancillary data that are used within GHRSST data files. The GDS document has been developed for data providers who wish to produce any level of GHRSST data product and for all users wishing to fully understand GHRSST product conventions, GHRSST data file contents, GHRSST and Climate Forecast definitions for SST, and other useful information. For a complete discussion and access to data products and services, see https://www.ghrsst.org, which is a central portal for all GHRSST activities. ```{tableofcontents} ``` _sources/l4.md0000664000175000017500000002630114726356062013752 0ustar jfpiollejfpiolle--- jupytext: formats: md:myst text_representation: extension: .md format_name: myst --- (l4)= # Level 4 (L4) Product Specification ## Overview description of the GHRSST L4 data product L4 products are the analyzed SST products, usually derived from GHRSST L2P products. L4 data products should ideally be made available within the GHRSST R/GTS framework to the user community within 24 hours. L4 products include gap-free analyzed SST data together with a number of ancillary fields that simplify interpretation and application of the SST data. Data providers are responsible for providing documentation on their analysis procedure. The common format of L4 products allows data users to code with the security that as new SST data products are brought on-line, very minimal code changes are required to make full use of a new L4 product. Time previously spent on coding different I/O routines for each satellite data set can be spent working with the data to produce results. The GHRSST Science Team determined that there will be 4 mandatory fields that form the core data content of a GHRSST L4 data file. In addition to global attributes and geo-location information, producers must include the following within a L4 file: - Sea Surface temperature data (SST) - Error estimates for SST data - Sea ice fraction (only and sea ice covered areas) - Land/sea/ice flag In addition, there are a number of optional fields that may be used at the data provider’s discretion. The GHRSST L4 file contents are summarized in {numref}`l4_content_summary` below. ```{table} Summary description of the contents within a GHRSST L4 data product :name: l4_content_summary | Description | Required | |----------------------------------------|-----------| | **Coordinate variables** | Information to permit locating data on grids, as defined in {numref}`coordinate_variables` | | **Data record variables** | Core and auxiliary variables as defined in {numref}`l4_records` | | **Global Attributes** | A collection of required global attributes describing general characteristics of the file, as defined in section {numref}`global_attributes` | ``` ## L4 data record format specification L4 analysed data products are derived from an analysis procedure implemented at regular intervals (daily, six-hourly or other time periods). L4 data products include SST, error statistics, sea ice fraction, land/sea/ice mask, and other optional data for each grid-cell. A **6-byte** experimental block is available for data providers to test new aspects of the file or information specific to the analysis system that will eventually transition into a GHRSST standard L4 analysis field once tested. {numref}`l4_records` describes the format of GDS L4 variables that should be created for each L4 grid cell. In the following sections, each variable within the L4 data file is described in detail. ```{table} L4 SST product data records :name: l4_records | Variable Name | Description | Units | Storage type | |-----------------------|------------------------|--------|-----| | [analysed_sst](__l4_analysed_sst) | SST from analysis system | K (kelvin) | short | | [analysis_error](__l4_analysis_error) | Error standard deviation estimate | K (kelvin) | short | | [sea_ice_fraction](__l4_sea_ice_fraction) | Fractional Sea Ice area concentration | 1 (unitless) | byte | | [sea_ice_fraction_error](__l4_sea_ice_fraction_error) | If the error estimates on the sea ice field are available, it is recommended to provide this information as an experimental field | 1 (unitless) | byte | | [mask](__l4_mask) | land/ice/lake mask | | byte | | [other fields](__l4_optional_fields) | Optional/experimental fields defined by data provider | | | ``` (__l4_analysed_sst)= ### `analysed_sst` The variable `analysed_sst` will be included with the format requirements shown in {numref}`l4_analysed_sst`. The data provider is responsible for providing GHRSST with documentation on how the analysed SST is determined. Note that the RDAC should place the `_FillValue` value in pixels that fall on land. ```{table} CDL example description of **analysed_sst** variable :name: l4_analysed_sst | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|--------------|----------------------------------|----------| | short | `analysed_sst` | SST values from analysis systems | K (kelvin) | ``` ```{code-cell} :tags: [remove-input] :name: l4_analysed_sst !ncdump -h samples/l4_full_example.nc | grep $'[ , \t]analysed_sst[(,:]'| sed 's/[[:space:]]//' ``` (__l4_analysis_error)= ## `analysis_error` The variable `analysis_error` will be included with the format requirements shown in {numref}`l4_analysis_error`. The data provider is responsible for providing GHRSST with documentation on how `analysis_error` is determined. ```{table} CDL example description of analysis\_error variable :name: l4_analysis_error | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|----------------|-------------------------------------|----------| | short | `analysis_error` | Error estimate from analysis system | K (kelvin) | ``` ```{code-cell} :tags: [remove-input] !ncdump -h samples/l4_full_example.nc | grep $'[ , \t]analysis_error[(,:]'| sed 's/[[:space:]]//' ``` (__l4_sea_ice_fraction)= ## `sea_ice_fraction` The variable sea_ice_fraction will be included with the format requirements shown in {numref}`l4_sea_ice_fraction`. Some SST data are contaminated in part or wholly by sea ice and the L4 variable `sea_ice_fraction` is used to quantify the fraction of an area contaminated with sea ice. If the error estimates on the sea ice field are available, it is recommended to provide this information as an experimental variable called `sea_ice_fraction_error`. ```{table} CDL example description of **sea\_ice\_fraction** variable :name: l4_sea_ice_fraction | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|------------------|---------------------------------------|-----------| | byte | `sea_ice_fraction` | Fractional sea ice area concentration | 1 (unitless) | ``` ```{code-cell} :tags: [remove-input] !ncdump -h samples/l4_full_example.nc | grep $'[ , \t]sea_ice_fraction[(,:]'| sed 's/[[:space:]]//' ``` (__l4_mask)= ## `mask` The variable `mask` will be included with the format requirements shown in {numref}`l4_mask`. ```{table} CDL example description of **mask** variable :name: l4_mask | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|----------|------------------------|----------| | byte | `mask` | land/sea/ice/lake mask | none | ``` ```{code-cell} :tags: [remove-input] !ncdump -h samples/l4_full_example.nc | grep $'[ , \t]mask[(,:]'| sed 's/[[:space:]]//' ``` ```{admonition} Comments: Comments This is a land/sea/ice mask with the following bit values: - Bit 0:1 = water in grid - Bit 1:1 = land in grid - Bit 2:1 = optional, lake surface in grid - Bit 3:1 = sea ice - Bit 4:1 = optional, river surface in grid - Bits [5-7] spare Note that the lake and river surface bit values are optional. The `source` attribute should list any data product used in creating this mask, a semi-colon separated list of identifiers **\\_\\_\**. ``` (__l4_sea_ice_fraction_error)= ## Optional Variable **sea_ice_fraction_error** If the error estimates on the sea ice field are available, it is recommended to provide this information as an optional field called `sea_ice_fraction_error`. The data provider is responsible for providing GHRSST with documentation on how `sea_ice_fraction_error` is estimated. ```{table} CDL example description of **sea_ice_fraction_error** variable :name: l4_sea_ice_fraction_error | **Storage type** | **Name** | **Description** | **Unit** | |-------------------|------------------------|---------------------------------------|-----------| | byte | `sea_ice_fraction_error` | Fractional sea ice area concentration error | 1 | ``` ```{code-cell} :tags: [remove-input] !ncdump -h samples/l4_full_example.nc | grep $'[ , \t]sea_ice_fraction_error[(,:]'| sed 's/[[:space:]]//' ``` (__l4_optional_fields)= ### Optional experimental L4 variables included by data provider Flexibility of L4 product content is provided through the netCDF API, which allows fully self-describing fields and additional L4 variables may be included by L4 data providers if they are considered relevant for L4 users. The GDS-{{gds_version}} also permits the inclusion of R&D variables (e.g. estimates of sea ice fraction error, SST anomaly, etc.) and 6 bytes per pixel are available in total for optional/experimental variables in any combination (i.e., variables can be defined as 6 x byte, 3 x short, 2 x short + 2 x byte, etc). The use of optional/experimental variables provides a limited amount of flexibility within the GDS-{{gds_version}} for regional user requirements while maintaining an overall upper limit on GDS-{{gds_version}} L4 products for data management groups and archive scaling. In exceptional cases a waiver on the 6 byte ceiling can be requested to extend up to 12 bytes per pixel. The GDS-{{gds_version}} issues the following guidance on the inclusion of optional or experimental variables within L4 data products: - The sum total of all experimental variables shall not increase L4 record size by more than **6 bytes** per SST pixel. A **waiver** can be requested for higher amounts up to 12 bytes. - CF-1.7 or later compliance should be maintained for all optional/experimental variables. Where available, a standard_name attribute should be used. - It is permitted to use a provider defined coordinate variable associated with experimental fields but this shall be documented in data provider documentation. - Time difference data (dtime values) should be provided for variables when appropriate. - The source of data should be indicated: in the single source case as a variable attribute; as a dedicated variable when mixed data sources are present. - Use of experimental variables requires clear documentation by the GHRSST producer. They shall provide adequate documentation that describes each variable following the CDL examples provided in this document. - The variable attribute `comment` shall be used to provide a URL link to a full description of each data producer defined variable included in the L4 product. - Experimental L4 variables if present in an L4 product will be included with the minimum format requirements shown in {numref}`__l4_sea_ice_fraction_error` - Additional global variables may be declared within the L4 product. ## CDL example L4 dataset The following CDL has been generated for a detailed example global L4 dataset: ```{code-cell} :tags: [remove-input] !ncdump -h samples/l4_full_example.nc ``` _sources/coordinates.md0000664000175000017500000003144014714712730015740 0ustar jfpiollejfpiolle--- jupytext: formats: md:myst text_representation: extension: .md format_name: myst --- (coordinate_variables)= # Coordinate variables NetCDF coordinate variables provide scales for the space and time axes for the multidimensional data arrays, and must be included for all dimensions that can be identified as spatio-temporal axes. Coordinate arrays are used to geolocate data arrays on non-orthogonal grids, such as images in the original pixel/scan line space, or complicated map projections. Required attributes are `units` and `_FillValue`. Elements of the coordinate array need not be monotonically ordered. The data type can be any and scaling may be implemented if required. `add_offset` and `scale_factor` have to be adjusted according to the sensor resolution and the product spatial coverage. If the packed values can not stand on a short, float can be used instead (multiplying the size of these variables by two). ## Temporal coordinates `time` is the reference time of the SST data array. The GDS-{{gds_version}} specifies that this reference time should be extracted or computed to the nearest second and then coded as continuous UTC time coordinates in **seconds from 00:00:00 UTC January 1, 1981** (which is the definition of the GHRSST origin time, chosen to approximate the start of useful AVHRR SST data record). Note that the use of UDUNITS in GHRSST implies that that calendar to be used is the default mixed Gregorian/Julian calendar. The reference time used is dependent on the of the data and is defined as follows: | Processing level | Reference time | |------------------|-------------------------------------| | L2P | start time of granule | | L3U | start time of granule | | L3C | centre time of the collation window | | L3S | centre time of the collation window | | L4 | nominal time of the analysis | The coordinate variable `time` is intended to minimize the size of the `sst_dtime` variable (e.g., see {numref}`__l2p_sst_dtime`), which stores offsets from the reference time in seconds for each SST pixel. `time` also facilitates aggregation of all files of a given dataset along the time axis with such tools as THREDDS or when building data cubes. ## Spatial coordinates **x** (columns) and **y** (lines) grid dimensions are referred either as `lat` and `lon` or as `ni` and `nj`. `lon` and `lat` must be used if data are mapped on a regular grid (some geostationary products). `ni` and `nj` are used if data are mapped on a non-regular grid (curvilinear coordinates) or following the sensor scanning pattern (scan line, swath). It is preferred that `ni` should be used for the across-track dimension and `nj` for the along-track dimension. Coordinate vectors are used for data arrays located on orthogonal (but not necessarily regularly spaced) grids, such as a geographic (lat-lon) map projections. The only required attribute is `units`. The elements of a coordinate vector array should be in monotonically increasing or decreasing order. The data type can be any and scaling may be implemented if required. A `coordinates` variable attribute (`coordinates = "lon lat" ;`) must be provided if the data are on a non-regular lat/lon grid (map projection or swath data). A `grid_mapping` variable attribute (`grid_mapping = "" ;`) must be provided if the data are mapped following a projection. Refer to the CF convention[^footnote2] for standard projection names. ```{admonition} Note on lat/lon arrays `lat` and `lon` arrays are the only arrays stored as float in GHRSST product files and therefore can represent a major fraction of the overall data volume. As an optimization factor, producers are encouraged to make use of the `least_significant_digit` argument when creating these NetCDF variables (refer for instance to https://unidata.github.io/netcdf4-python/): in most current GHRSST products, there is no need for a precision larger than 3 digits and it can be a big volume saver. ``` ### Regular latitude/longitude grids This is the simplest case. Many Level 3 and Level 4 products as well as some geostationary L2P products are provided on a regular lat/lon grid. On such a projection, only two coordinate variables are requested and they can be stored as vector arrays. Longitudes should range from -180 to +180, corresponding to 180 degrees West to 180 degrees East. Latitudes should range from -90 to +90, corresponding to 90 degrees South to 90 degrees North. There should be no `_FillValue` for latitude and longitude and all SST pixels should have a valid latitude and longitude value. It is recommended that for Level 3 and Level 4 data products the `time` dimension be specified as **unlimited**. Note that the `time` dimension for L2P data files is strictly defined as `time=1` (unlimited dimension not allowed). This strict definition is because L2P data are swath based and the geospatial information may change across consecutive time slabs. Although in GHRSST L3 and L4 granules there is only one `time` dimension and variable `time` has only one value (seconds since 1981), setting an unlimited dimension for `time` dimension will allow netCDF tools and utilities to easily concatenate (and average for example) a series of time consecutive GHRSST granules. The following CDL is provided as an example: ``` netcdf example { dimensions: lat = 1801 ; lon = 3600 ; time = UNLIMITED ; // (strictly set to 1 for L2P) variables: ... } ``` For these cases, dimension and coordinate variables shall be used for a regular lat/lon grid as shown in {numref}`regular_grid_coords`. No specific variable attributes are required for other variables (like `sea_surface_temperature` as shown in the example given in {numref}`regular_grid_coords`). ```{table} Example CDL for geographic regular latitude/longitude grids :name: regular_grid_coords | geographic regular latitude/longitude grids | | -------------------------------------------------- | ``` ```{code-cell} :tags: [remove-input] :name: regular_grid_coords !ncdump -h samples/regular_grid.nc ``` ### Non-regular latitude/longitude grids (projection) For gridded data using a specific projection (such as stereographic projection), lat/lon have to be stored in 2-D arrays. When data are gridded following the sensor pattern, no projection can be associated and lat/lon data have to be stored in 2-D arrays. Dimensions cannot be referred to as lat/lon anymore since the **x** and **y** axes of the grid are not related to the latitude or longitude axis. Each variable must explicitly provide a reference to its coordinate variables (`coordinates` variable attribute) and to the related projection (`grid_mapping` variable attribute) described in a specific variable (for example, `Lambert_Azimuthal_Grid",` in the example given in {numref}`non_regular_grid_coords_projection`, refer to CF convention [^footnote2] for standard projection names). In these cases, dimension and coordinate variables shall be used for a non-regular lat/lon grid (projection) as shown in {numref}`non_regular_grid_coords_projection`. A specific projection coordinate variable shall be added (for example, `Lambert_Azimuthal_Grid`), following the CF-1.7 or later convention. The specific variable attributes `coordinates = "lon lat"` and`grid_mapping = "Lambert_Azimuthal_Grid"` are required for each other variables (like `sea_surface_temperature` in the example given in {numref}`non_regular_grid_coords_projection`). Note that variable attributes such as `grid_mapping` may be set differently (when using a different kind of projection) or completely removed (for swath products or regular grids if required). ```{table} Example CDL for non-regular latitude/longitude grids (projection) :name: non_regular_grid_coords_projection | non-regular latitude/longitude grids (projections) | | -------------------------------------------------- | ``` ```{code-cell} :tags: [remove-input] :name: non_regular_grid_coords_projection !ncdump -h samples/nonregular_grid_projection.nc ``` ### Non-regular latitude/longitude grids (projection) – alternative without explicit latitude/longitude For gridded data using a fixed specific projection (such as geostationary projection), the same lat/lon 2-D arrays are repeated from file to file. If a fixed projection can be associated to lat/lon data, it is also permitted by CF convention to provide a projection variable defining this projection, instead of providing explicit latitude/longitude 2-D arrays as in the previous section. This usually allows to save significant storage (which is interesting for products with a high temporal repetitiveness such as geostationary products in satellite projection) while being less user friendly since users will have to calculate their own latitude/longitude 2-D arrays from the projection parameters (this is done automatically in some CF compliant tools). The projection variable must be named with the projection name used in the product (like `geostationary` below). It is dimensionless and of type int. The naming and content of this projection variable is described in CF conventions[^footnote2]. The **x** (abscissa) and **y** (ordinate) rectangular coordinates must be provided in `ni` and `nj` variables, identified by the `standard_name`attribute values `projection_x_coordinate` and `projection_y_coordinate` respectively. In the case of this geostationary projection, the projection coordinates in this projection are directly related to the scanning angle of the satellite instrument, and their units are radians. Each variable must explicitly provide a reference to its coordinate variables (coordinates variable attribute) and to the related projection (`grid_mapping` variable attribute) described in a specific variable (e.g. geostationary in the example given in {numref}`non_regular_grid_coords_projection_no_latlon`; refer to CF convention[^footnote2] for standard projection names). In these cases, dimension and coordinate variables shall be used for a non-regular lat/lon grid (projection) as shown in {numref}`non_regular_grid_coords_projection_no_latlon`. A specific projection coordinate variable shall be added (for example, `geostationary`), following the CF-1.7 or later convention. The specific variable attributes `coordinates = "nj ni"` and `grid_mapping = "geostationary"` are required for each other variables (like `sea_surface_temperature` in the example given in {numref}`non_regular_grid_coords_projection_no_latlon`). ```{table} Example CDL for Non-regular latitude/longitude grids (projections) alternative form with no explicit latitudes/longitudes :name: non_regular_grid_coords_projection_no_latlon | non-regular latitude/longitude grids (projections) with no explicit latitude/longitude | | -------------------------------------------------- | ``` ```{code-cell} :tags: [remove-input] :name: non_regular_grid_coords_projection_no_latlon !ncdump -h samples/nonregular_grid_projection_no_latlon.nc ``` ### Non-regular latitude/longitude grids (swath) In this case where data are gridded following the sensor pattern, no projection can be associated and lat/lon data have to be stored in 2-D arrays, as it is the case for along-swath data for low earth orbiting sensors or geostationary orbiting sensor data in their native projection. Therefore it only applies to **L2P** processing level products. Dimensions cannot be referred to as lat/lon anymore since x and y axes of the grid are no more related to the latitude or longitude axis. Instead, dimensions `ni` and `nj`should be used to describe the swath. As a best practice, the `ni` dimension should refer to the cross-track direction and the `nj` dimension should refer to the along-track direction of a polar orbiting (or similar) satellite sensor swath. For geostationary sensors `ni` also refers to the cross-disk direction and `nj` the along-disk direction. Each variable must explicitly provide a reference to its coordinate variables (using the coordinates variable attribute) and pixel times must be encoded using the combination of `time`and `sst_dtime` coordinate variables. Dimension and coordinate variables shall be used for a non-regular lat/lon grid (swath product file) as shown in {numref}`non_regular_grid_coords`. The specific variable attribute `coordinates = "lon lat"` is required for each of the variables (like `sea_surface_temperature` below). ```{table} Example CDL for non-regular latitude/longitude grids (swath) :name: non_regular_grid_coords | non-regular latitude/longitude coordinates | | ------------------------------------------ | ``` ```{code-cell} :tags: [remove-input] :name: non_regular_grid_coords !ncdump -h samples/nonregular_grid.nc ``` [^footnote2]: http://cfconventions.org/cf-conventions/cf-conventions.html#appendix-grid-mappings_sources/structure.md0000664000175000017500000027536414726262110015500 0ustar jfpiollejfpiolle# GDS Data Product File Structure and attributes ## Overview of the GDS-{{gds_version}} netCDF File Format GDS-{{gds_version}} data files preferentially use the netCDF-4 Classic format. A major advantage to the use of NetCDF-4 format products is that it offers internal compression so that reading a given variable or some attributes does not require to explicitly decompress the entire file. These GDS-{{gds_version}} formatted data sets must comply with the **Climate and Forecast (CF) Conventions, v1.7 or later** [^footnote1] because these conventions provide a practical standard for storing oceanographic data in a robust, easily-preserved for the long-term, and interoperable manner. The CF-compliant netCDF data format is flexible, self-describing, and has been adopted as a de facto standard for many operational and scientific oceanography systems. Both netCDF and CF are actively maintained including significant discussions and inputs from the oceanographic community. The CF convention generalizes and extends the **Cooperative Ocean/Atmosphere Research Data Service (COARDS) Convention** [^footnote2] but relaxes the COARDS constraints on dimension order and specifies methods for reducing the size of datasets. The purpose of the CF Conventions is to require conforming datasets to contain sufficient metadata so that they are self-describing, in the sense that each variable in the file has an associated description of what it represents, physical units if appropriate, and that each value can be located in space (relative to earth-based coordinates) and time. In addition to the CF Conventions, GDS-{{gds_version}} formatted files follow some of the recommendations of the **Unidata Attribute Convention for Dataset Discovery (ACDD)** [^footnote3]. In the context of netCDF, a **variable** refers to data stored in the file as a vector or as a multidimensional array. Each variable in a GHRSST netCDF file consists of a 2-dimensional `[i x j]`, 3-dimensional `[i x j x k]`, or 4-dimensional `[i x j x k x l]` array of data. The dimensions of each variable must be explicitly declared in the dimension section. Within the netCDF file, **global attributes** are used to hold information that applies to the whole file, such as the data set title. Each individual variable must also have its own attributes, referred to as **variable attributes**. These variable attributes define, for example, an **offset**, **scale factor**, **units**, a **descriptive version of the variable name**, and a **fill value**, which is used to indicate array elements that do not contain valid data. Where applicable, SI units should be used and described by a character string, which is compatible with the Unidata UDUNITS-2 package [^footnote4]. All GHRSST GDS-{{gds_version}} files conform to this structure and share a common set of netCDF global attributes. These global attributes include those required by the CF Convention plus additional ones required by the GDS-{{gds_version}}. The required set of global attributes is described in {numref}`global_attributes` and entities within the GHRSST R/GTS framework are free to add their own, as long as they do not contradict the GDS-{{gds_version}} and CF requirements. Following the CF convention, each variable also has a set of variable attributes. The required variable attributes are described in {numref}`variable_attributes`. In a few cases, some of these variable attributes may not be relevant for certain variables or additional variable attributes may be required. In those cases, the variable descriptions in each of the [L2P](./l2p.md), [L3](./l3.md), [L4](./l4.md) product specifications will identify the differences and specify requirements for each product. As with the global attributes, entities within the GHRSST R/GTS framework are free to add their own variable attributes, as long as they do not contradict the GDS-{{gds_version}} and CF requirements. While the exact volumes can vary, an average L2P file will use about 33 bytes per pixel, an L3 file 28 bytes per pixel, and an L4 file about 8 bytes per pixel. The data type encodings for each variable are fixed except for the experimental fields, which are flexible and can chosen by the GHRSST producer. (global_attributes)= ## Global Attributes {numref}`__global_attributes` below summarizes the global attributes that are mandatory for every GDS-{{gds_version}} netCDF data file. More details on the CF-mandated attributes (as indicated in the *Source* column) are available at: http://cfconventions.org/cf-conventions/cf-conventions.html#attribute-appendix and information on the ACDD recommendations is available at https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3. ```{table} Mandatory global attributes for GDS-{{gds_version}} netCDF data files (blue are mandatory, purple are optional) :name: __global_attributes :class: global-attributes-css | Global Attribute Name | Format | Description | Example | Source | |----------------------------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ------ | | `Conventions` | string | A comma-separated list of the conventions that are followed by the dataset. For files that follow this versionof ACDD, include the string 'ACDD-1.3'.(This attribute is defined in NUG 1.7.) | `Conventions = "CF 1.7+, ACDD 1.3
ISO 8601";` | ACDD 1.3
CF 1.7++ | | `title` | string | A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is recommended by the NetCDF Users Guide (NUG) and the CF conventions. | `title = "VIIRS L2P Sea Surface Skin Temperature" ;` | ACDD 1.1
ACDD 1.3
CF 1.7+| | `summary` | string | A paragraph describing the dataset, analogous to an abstract for a paper. | `summary = "Sea surface temperature (SST) retrievals produced at the NASA OBPG for the Visible Infrared Imaging Radiometer Suite (VIIRS) sensor on the Suomi National Polar-Orbiting Parnership (Suomi NPP) platform. These have been reformatted to GHRSST GDS version 2 Level 2P specifications by the JPL PO.DAAC." ;` | ACDD 1.1
ACDD 1.3 | | `references` | string | Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions. | `references = "GHRSST Data Processing Specification v2r5" ;` | ACDD 1.3
CF 1.7+ | | `institution` | string | The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention. | `institution = "NASA Jet Propulsion Laboratory (JPL) Physical Oceanography Distributed Active Archive Center (PO.DAAC)/NASA Goddard Space Flight Center (GSFC), Ocean Biology Processing Group (OBPG)/University of Miami Rosential School of Marine and Atmospheric Science (RSMAS)" ;` |ACDD 1.1, ACDD 1.3
CF 1.7+| | `history` | string | Provides an audit trail for modifications to the original data. This attribute is also in the NetCDF Users Guide: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see NOAA EDM ISO Lineage guidance. | `history = "VIIRS L2P created at JPL PO.DAAC by combining OBPG SNPP_SST and SNPP_SST3, and outputing to the GHRSST GDS2 netCDF file format" ;` | ACDD 1.1
ACDD 1.3
CF 1.7+ | | `comment` | string | Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the CF Conventions. | `comment = "L2P Core without DT analysis or other ancillary fields; Night, Start Node:Descending, End Node:Descending; WARNING Some applications are unable to properly handle signed byte values. If values are encountered > 127, please subtract 256 from this reported value; Quicklook" ;` | ACDD 1.1
ACDD 1.3 | | `license` | string | Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text. GHRSST data sets should be freely and openly available to comply with the R/GTS framework, with no restrictions. However, if a user should submit a simple registration via a web form, for example, the URL could be given here. | `license = "GHRSST protocol describes data use as free and open.” ;` | ACDD 1.1
ACDD 1.3| | `id` | string | An identifier for the data set, provided by and unique within its naming authority. The combination of the ""naming authority"" and the ""id"" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include white space characters.


Here the unique GHRSST character string for this product. All GHRSST SST products have one, and they are listed in Erreur : source de la référence non trouvée.
| `id = "VIIRS_NPP-JPL-L2P-v2016.0" ;` | ACDD 1.1
ACDD 1.3 | | `naming_authority` | string | The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Fixed as “org.ghrsst” following ACDD convention. | `naming_authority = "org.ghrsst" ;` | ACDD 1.1
ACDD 1.3 | | `product_version` | string | Version identifier of the data file or product as assigned by the data creator. For example, a new algorithm or methodology could result in a new product_version. It may be different than the file version used in the file naming convention (Section 7).
| `product_version = "2016.0" ;` | ACDD 1.3 | | `uuid` | string | A uuid (Universal Unique Identifier) is a 128-bit number used to uniquely identify some object or entity on the Internet. Depending on the specific mechanisms used, a uuid is either guaranteed to be different or is, at least, extremely likely to be different from any other uuid generated until 3400 A.D. See http://en.wikipedia.org/wiki/Universally_Unique_Identifier for more information and tools.
| `uuid = "b6ac7651-7b02-44b0-942b-c5dc3c903eba" ;` | GDS | | `gds_version_id` | string | GDS version used to create this data file. For example, “2.1”. | | GDS | | `netcdf_version_id` | string | Version of netCDF libraries used to create this file. For example, “4.1.1” | | GDS | | `date_created` | string | The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended.

| `date_created = "2016-10-14T21:00:25" ;` | ACDD 1.1
ACDD 1.3 | | `date_modified` | string | The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended.

| `date_modified = "2016-10-14T21:00:25" ;` | ACDD 1.1
ACDD 1.3 | | `date_issued` | string | The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended.


| `date_issued = "2016-10-14T21:00:25" ;` | ACDD 1.1
ACDD 1.3 | | `date_metadata_modified` | string | The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended.

| `date_metadata_modified = "2016-10-14T21:00:25" ;` | ACDD 1.3 | | `file_quality_level` | integer | A code value:
0 = unknown quality
1 = extremely suspect (frequent problems, e.g. with known satellite problems)
2 = suspect (occasional problems, e.g. after launch)
3 = excellent (no known problems) | | GDS | | `spatial_resolution` | string | A string describing the approximate resolution of the product. For example, “1.1km at nadir” | | GDS | | `time_coverage_start` | string | Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, of “yyyy-mm-ddThh:mm:ssZ”. The exact meaning of this attribute depends the type of granule:
L2P: first measurement in granule (identical to ‘time’ netCDF variable)

L3U: start time of granule

L3C and L3S: representative start time of first measurement in the collation

L4: representative start time of the analysis (start_time and stop_time together represent the valid period of the L4 granule)

| `time_coverage_start = "2016-09-01T08:12:01" ;` | ACDD 1.1
ACDD 1.3 | | `time_coverage_end` | string | Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, of “yyyy-mm-ddThh:mm:ssZ”. The exact meaning of this attribute depends the type of granule:
L2P: last measurement in granule

L3U: stop time of granule

L3C and L3S: representative stop time of last measurement in collation

L4: representative stop time of the analysis (start_time and stop_time together represent the valid period of the L4 granule)
| `time_coverage_end = "2016-09-01T08:17:59" ;` | ACDD 1.1
ACDD 1.3 | | `instrument` | string | Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.

We recommend for consistency to use the CEOS mission table (http://database.eohandbook.com/database/instrumenttable.aspx). Provide as a comma separated list if there is more than one. | `sensor = "VIIRS" ;` | ACDD 1.3 | | `instrument_vocabulary` | string | Controlled vocabulary for the names used in the ""instrument"" attribute.
| `instrument_vocabulary = "CEOS instrument table" ;` | ACDD 1.3 | | `metadata_link` | string | A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute. It is recommended to link to the product description in the GHRSST central catalogue.
| `metadata_link = "http://podaac.jpl.nasa.gov/ws/metadata/dataset/?format=iso&shortName=VIIRS-JPL-L2P-v2016.0" ;` | ACDD 1.3 | | `keywords` | string | A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also "keywords_vocabulary" attribute). | `keywords = "Oceans, Ocean Temperature, Sea Surface Temperature , Sea Surface Skin Temperature" ;` | ACDD 1.1
ACDD 1.3 | | `keywords_vocabulary` | string | If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g.,“NASA Global Change Master Directory (GCMD) Science Keywords” as defined in [AD-10]) and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key. | `keywords_vocabulary = "NASA Global Change Master Directory (GCMD) Science Keywords" ;`[AD-10] | ACDD 1.1
ACDD 1.3 | | `standard_name_vocabulary` | string | The name and version of the controlled vocabulary from which variable standard names are taken. (Values for any standard_name attribute must come from the CF Standard Names vocabulary for the data file or product to comply with CF.)
| CF Standard Name Table v27'. | ACDD 1.1
ACDD 1.3 | | `geospatial_lat_min` | float | Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.

| `geospatial_lat_min = -63.1404f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_lat_max` | float | Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_max specifies the northernmost latitude covered by the dataset.
| `geospatial_lat_max = -36.7432f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_lat_units` | string | Units for the latitude axis described in ""geospatial_lat_min"" and ""geospatial_lat_max"" attributes. These are presumed to be ""degree_north""; other options from udunits may be specified instead.
| `geospatial_lat_units = "degrees_north" ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_lat_resolution` | float | Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: '100 meters', '0.1 degree'. For level 1 and 2 swath data this is an approximation of the pixel resolution.
| `geospatial_lat_resolution = 0.0075f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_lon_min` | float | Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max.
| `geospatial_lon_min = -143.09f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_lon_max` | float | Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175).
| `geospatial_lon_max = -88.893f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_lon_units` | string | Units for the longitude axis described in ""geospatial_lon_min"" and ""geospatial_lon_max"" attributes. These are presumed to be ""degree_east""; other options from udunits may be specified instead.
| `geospatial_lon_units = "degrees_east" ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_lon_resolution` | float | Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: '100 meters', '0.1 degree'. For level 1 and 2 swath data this is an approximation of the pixel resolution.
| `geospatial_lon_resolution = 0.0075f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_vertical_min` | float | Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.
| `geospatial_vertical_min = 0.00f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_vertical_max` | float | Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units.
| `geospatial_vertical_max = 1000.00f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_vertical_resolution` | float | Information about the targeted vertical spacing of points. Example: '25 meters'
| `geospatial_vertical_resolution = 25.0f ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_vertical_units` | string | Units for the vertical axis described in "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level). | `geospatial_vertical_units = 'meters' ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_vertical_positive` | string | One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum. Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center.
| `geospatial_vertical_positive = 'down' ;` | ACDD 1.1
ACDD 1.3 | | `geospatial_bounds` | string | Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system. The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the (-180, 180) range. Example: "POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))". | `geospatial_bounds = "(-143.09, -63.1404, -88.893, -36.7432)" ;` | ACDD 1.1 ACDD 1.3 | | `geospatial_bounds_crs` | string | The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute. If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: "EPSG:4979" (the 3D WGS84 CRS), "EPSG:4047". | `geospatial_bounds_crs = "WGS84" ;` | ACDD 1.3 | | `geospatial_bounds_vertical_crs` | string | The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended. There is no default for this attribute when not specified. Examples: ""EPSG:5829"" (instantaneous height above sea level), ""EPSG:5831"" (instantaneous depth below sea level), or ""EPSG:5703"" (NAVD88 height).
| `geospatial_bounds_vertical_crs = "EPSG:5831" ;` | ACDD 1.3 | | `acknowledgment` | string | A place to acknowledge various types of support for the project that produced this data.
| `acknowledgment = "The VIIRS L2P sea surface temperature data are sponsored by NASA. Data may be freely distributed" ;` | ACDD 1.1
ACDD 1.3 | | `creator_name` | string | The name of the person (or other creator type, such as a RDAC, specified by the creator_type attribute) principally responsible for creating this data.
| `creator_name = "JPL PO.DAAC" ;` | ACDD 1.1
ACDD 1.3 | | `creator_url` | string | The URL of the of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data.
| `creator_url = "http://podaac.jpl.nasa.gov" ;` | ACDD 1.1
ACDD 1.3 | | `creator_email` | string | The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data. | `creator_email = "ghrsst@jpl.nasa.gov" ;` | ACDD 1.1
ACDD 1.3 | | `creator_type` | string | Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person. For a RDAC, use here ‘institution’. | `creator_type = "institution" ;` | ACDD 1.3 | | `creator_institution` | string | The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution.
| `creator_institution = "JPL PO.DAAC/GHRSST";` | ACDD 1.3 | | `project` | string | The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.

| `"Group for High Resolution Sea Surface Temperature” ;` | ACDD 1.1
ACDD 1.3 | | `program` | string | The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples:
'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.

| `program= " NASA Earth Science Data Information and System (ESDIS)" ;` | ACDD 1.3 | | `contributor_name` | string | The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters).
| `contributor_name = "PO.DAAC/OBPS/REMAS" ;` | ACDD 1.3 | | `contributor_role` | string | The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names.
| `contributor_role = "PO.DAAC convert the VIIRSS_NPP SST to GDS2 format, OBPS processed the L2P SST, and RSMAS provided the algorithm model ";` | ACDD 1.3 | | `publisher_name` | string | The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format. | `publisher_name = "The GHRSST Project Office" ;` | ACDD 1.1
ACDD 1.3 | | `publisher_url` | string | The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format. | `publisher_url = "http://www.ghrsst.org" ;` | ACDD 1.1
ACDD 1.3 | | `publisher_email` | string | The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format.
| `publisher_email = "ghrsst-po@nceo.ac.uk" ;` | ACDD 1.1
ACDD 1.3 | | `publisher_type` | string | Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person.
| `publisher_type = "institution" ;` | ACDD 1.3 | | `publisher_institution` | string | The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name.
| `publisher_institution = "PO.DAAC" ;` | ACDD 1.3 | | `processing_level` | string | A textual description of the processing (or quality control) level of the data.


GHRSST definitions are the options: L2P, L3U, L3C, L3S, L4 and GMPE
| `processing_level = "L2P" ;` | ACDD 1.1
ACDD 1.3 | | `cdm_data_type` | string | The data type, as derived from Unidata's Common Data Model Scientific Data types and understood by THREDDS. (This is a THREDDS ""dataType"", and is different from the CF NetCDF attribute 'featureType', which indicates a Discrete Sampling Geometry file in CF.). “swath” or “grid”.
| `cdm_data_type = "swath" ;` | ACDD 1.1
ACDD 1.3 | ``` (variable_attributes)= ## Variable Attributes ```{table} Variable attributes for GDS-2.1 netCDF data files (blue are mandatory, purple are optional, orange are deprecated attributes from previous GDS versions) :name: var_attributes :class: "var-attributes-css" | Variable Attribute Name | Format | Description | | Source | |-------------------------|---------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------|----------------------------| | `_FillValue` | Must be the same as the packed variable type | Assigned value in the data file designating a null or missing observation.
This value must be of the same type as the storage (packed) type; should be set as the minimum value for this type. Note that some netCDF readers are unable to cope with signed bytes and may, in these cases, report fill as 128. Some cases will be reported as unsigned bytes 0 to 255. Required for the majority of variables except mask and l2p_flags.
Best practices specifies that for satellite datasets there should not be a `_FillVlalue` for geolocation or time variables. | `_FillValue = -32767s ;` | CF 1.7+ | | `units` | String | The units of the variable's data values. This attribute value should be a valid udunits[^footnote6] string. The `units` attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention. For a given variable (e.g. wind speed), these must be the same for each dataset. Required for the majority of variables except mask, quality_level, and l2p_flags. | `units = "K" ;` | ACDD 1.1
ACDD 1.3
CF 1.7+ | | `scale_factor` | Must be expressed in the unpacked data type | Slope of scaling relationship applied to transform measuement data to appropriate geophysical quantity representations. Should not be used if the `scale_factor` is '1' and `add_offset` is '0'
To be multiplied by the variable to recover the original value. Defined by the producer. Valid values within `value_range` should be transformed by scale_factor and add_offset, otherwise skipped to avoid floating point errors.
|`scale_factor = 0.005f ;` | CF 1.7+ | | `add_offset` | Must be expressed in the unpacked data type | Intercept of scaling relationship applied to transform measurement data to appropriate geophysical quantity representations. Should not be used if the `scale_factor` is '1' and `add_offset` is '0'
To be added to the variable after multiplying by the scale factor to recover the original value. If only one of `scale_factor` or `add_offset` is needed, then both should be included anyway to avoid ambiguity, with `scale_factor` defaulting to 1.0 and `add_offset` defaulting to 0.0. Defined by the producer. Valid values within `value_range` should be transformed by `scale_factor` and `add_offset`, otherwise skipped to avoid floating point errors. | `add_offset = 273.15f ;` | CF 1.7+ | | `long_name` | String | A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention. | `long_name = "sea surface temperature" ;` | ACDD 1.1
ACDD 1.3
CF 1.7+ | | `valid_range` | Must be the same as the packed variable type | Comma separated minimum and maximum values of the physical quantity defining the valid measurement range. The fill value should be outside this valid range. Note that some netCDF readers are unable to cope with signed bytes and may, in these cases, report valid min as 129. Some cases as unsigned bytes 0 to 255. Values outside of the `valid_range` will be treated as missing values. When all values except the one in `_FillValue` are valid, this attribute is not required. It is therefore not necessary in GDS for variables for which the `_FillValue` attribute is defined. | `valid_range = -32767s, 32767 ;` | CF 1.7+ | | `standard_name` | String | A long descriptive name for the variable taken from a controlled vocabulary of variable names. We require using the CF convention and the variable names from the CF standard name table[^footnote7]. This attribute is recommended by the CF convention. Do not include this attribute if no standard_name exists. | `standard_name = "sea_surface_skin_temperature" ;` | ACDD 1.1
ACDD 1.3
CF 1.7+ | | `comment` | String | Optional attribute field allowing provision of further free-form information about the variable or the methods used to produce it. | `comment = "sea surface temperature from 11 and 12 um (thermal IR) channels" ;` | CF 1.7+ | | `source` | string | For L2P and L3 files: For a data variable with a single source, use the GHRSST unique string if the source is a GHRSST SST product. For other sources, following the best practice described in Section {numref}`product_codes` to create the character string.
If the data variable contains multiple sources, set this string to be the relevant “source of” variable name. For example, if multiple wind speed sources are used, set `source = source_of_wind_speed`.

For L4 and GMPE files: follow the source convention used for the global attribute of the same name, but provide in the comma-separated list only the sources relevant to this variable. | `source = "ECMWF" ;` | CF 1.7+ | | `references` | string | Published or web-based references that describe the data or methods used to produce it. Note that while at least one reference is required in the global attributes (See {numref}`global_attributes`), references to this specific data variable may also be given. | | CF 1.7+ | | `axis` | String | Corresponding variable axis for plotting (eg. X, Y, Z).
For use with coordinate variables only. The attribute `axis` may be attached to a coordinate variable and given one of the values “X”, “Y”, “Z”, or “T”, which stand for a longitude, latitude, vertical, or time axis respectively[^footnote1]. | `axis = "Y";` | CF 1.7+ | | `positive` | String | For use with a vertical coordinate variables only. May have the value “up” or “down”. For example, if an oceanographic netCDF file encodes the depth of the surface as 0 and the depth of 1000 meters as 1000 then the axis would set positive to “down”. If a depth of 1000 meters was encoded as -1000, then positive would be set to “up”. See the section on vertical coordinate in CF Convention[^footnote1] | `positive = "up" ;` | CF 1.7+ | | `coordinates` | String | This attribute contains a space separated list of all the coordinates corresponding to the variable. The list should contain all the auxiliary coordinate variables and optionally the coordinate variables.

See the section on coordinate system in CF Convention[^footnote1]. This attribute must be provided if the data are on a non-regular lat/lon grid (map projection or swath data). | `coordinates = "time lat lon";` | CF 1.7+ | | `grid_mapping` | String | Describes the horizontal coordinate system used by the data. The grid_mapping attribute should point to a variable which would contain the parameters corresponding to the coordinate system. That named variable is called a grid mapping variable and is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. There are typically several parameters associated with each coordinate system. CF defines a separate attributes for each of the parameters. Some examples are `semi_major_axis`, `inverse_flattening`, `false_easting`. See the section on mappings-and-projections in CF Convention[^footnote1]. | `grid_mapping = "geostationary";` | CF 1.7+ | | `flag_meanings` | String | Define the physical meaning of each `flag_masks` bit field or `flag_values` value with a single text string. | `flag_meanings = "microwave land ice lake river" ;` | CF 1.7+ | | `flag_values` | Must be the same as the variable type | Its values identify the flagged conditions by performing a bitwise AND of the variable value and each flag masks value. For example, if the variable value is of type unsigned byte and equal to 5 and the flag_masks are 1b, 2b, 4b, 8b, 16b, 32b. The binary encoding of 5 is 00000101 and the binary encoding of the flags are 00000001, 00000010, 00000100, 00001000, 00010000, 00100000. Now bitwide AND of the value with the masks returns 00000001, 00000000, 00000100, 00000000, 00000000, 00000000 respectively or 1b,0,4b,0,0,0,0,0 in decimal. So the masks corresponding to 1b and 4b are ""true"", rest are ""false"". Used primarily for quality_level and “source_of_xxx” variables. | `flag_values = 1b, 5b ;` | CF 1.7+ | | `flag_masks` | Must be the same as the variable type | A number of independent Boolean conditions using bit field notation by setting unique bits in each `flag_masks` value. The `flag_masks` attribute is the same type as the variable to which it is attached, and contains a list of values matching unique bit fields. (CF document, Flags section[^footnote1]). Used primarily for `l2p_flags` variable. | `flag_masks = 1b, 2b, 4b, 8b, 16b;` | CF 1.7+ | | `depth` | String | Use this to indicate the depth for which the SST data are valid. | `depth= "1m" ;` | GDS | | `height` | String | Use this to indicate the height for which the wind data are specified. | `height= "10m" ;` | GDS | | `time_offset` | float | Difference in hours between an ancillary field such as wind_speed and the SST observation time | `time_offset= 3. ;` | GDS | | `coverage_content_type` | String | An ISO 19115-3 code to indicate the source of the data `MD_CoverageContentTypeCode` [^footnote5]. For example, `image`, `thematicClassification`, `physicalMeasurement`, `auxiliaryInformation`, `qualityInformation`, `referenceInformation`, `modelResult`, or `coordinate`. | `coverage_content_type = "physicalMeasurement" ;` | ACDD 1.1
ACDD 1.3 | ``` [^footnote1]: netCDF Climate and Forecast (CF) Metadata Conventions version 1.7 or later available from http://cfconventions.org [^footnote2]: COARDS Conventions available from https://ferret.pmel.noaa.gov/Ferret/documentation/coards-netcdf-conventions [^footnote3]: Unidata Attribute Conventions for Dataset Discovery (ACDD), available from https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3 [^footnote4]: UDUNITS-2 package available from https://www.unidata.ucar.edu/software/udunits/ [^footnote5]: https://geonetwork-opensource.org/manuals/3.10.x/en/annexes/standards/iso19115-3.2018.html#standard-codelists-coverage-content-mrc-md-coveragecontenttypecode [^footnote6]: http://www.unidata.ucar.edu/software/udunits/udunits-1/udunits.txt [^footnote7]: http://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html_sphinx_design_static/0000775000175000017500000000000014744715173015637 5ustar jfpiollejfpiolle_sphinx_design_static/design-tabs.js0000664000175000017500000000533414744715173020402 0ustar jfpiollejfpiolle// @ts-check // Extra JS capability for selected tabs to be synced // The selection is stored in local storage so that it persists across page loads. /** * @type {Record} */ let sd_id_to_elements = {}; const storageKeyPrefix = "sphinx-design-tab-id-"; /** * Create a key for a tab element. * @param {HTMLElement} el - The tab element. * @returns {[string, string, string] | null} - The key. * */ function create_key(el) { let syncId = el.getAttribute("data-sync-id"); let syncGroup = el.getAttribute("data-sync-group"); if (!syncId || !syncGroup) return null; return [syncGroup, syncId, syncGroup + "--" + syncId]; } /** * Initialize the tab selection. * */ function ready() { // Find all tabs with sync data /** @type {string[]} */ let groups = []; document.querySelectorAll(".sd-tab-label").forEach((label) => { if (label instanceof HTMLElement) { let data = create_key(label); if (data) { let [group, id, key] = data; // add click event listener // @ts-ignore label.onclick = onSDLabelClick; // store map of key to elements if (!sd_id_to_elements[key]) { sd_id_to_elements[key] = []; } sd_id_to_elements[key].push(label); if (groups.indexOf(group) === -1) { groups.push(group); // Check if a specific tab has been selected via URL parameter const tabParam = new URLSearchParams(window.location.search).get( group ); if (tabParam) { console.log( "sphinx-design: Selecting tab id for group '" + group + "' from URL parameter: " + tabParam ); window.sessionStorage.setItem(storageKeyPrefix + group, tabParam); } } // Check is a specific tab has been selected previously let previousId = window.sessionStorage.getItem( storageKeyPrefix + group ); if (previousId === id) { // console.log( // "sphinx-design: Selecting tab from session storage: " + id // ); // @ts-ignore label.previousElementSibling.checked = true; } } } }); } /** * Activate other tabs with the same sync id. * * @this {HTMLElement} - The element that was clicked. */ function onSDLabelClick() { let data = create_key(this); if (!data) return; let [group, id, key] = data; for (const label of sd_id_to_elements[key]) { if (label === this) continue; // @ts-ignore label.previousElementSibling.checked = true; } window.sessionStorage.setItem(storageKeyPrefix + group, id); } document.addEventListener("DOMContentLoaded", ready, false); _sphinx_design_static/sphinx-design.min.css0000664000175000017500000014030714744715173021720 0ustar jfpiollejfpiolle.sd-bg-primary{background-color:var(--sd-color-primary) !important}.sd-bg-text-primary{color:var(--sd-color-primary-text) !important}button.sd-bg-primary:focus,button.sd-bg-primary:hover{background-color:var(--sd-color-primary-highlight) !important}a.sd-bg-primary:focus,a.sd-bg-primary:hover{background-color:var(--sd-color-primary-highlight) !important}.sd-bg-secondary{background-color:var(--sd-color-secondary) !important}.sd-bg-text-secondary{color:var(--sd-color-secondary-text) !important}button.sd-bg-secondary:focus,button.sd-bg-secondary:hover{background-color:var(--sd-color-secondary-highlight) !important}a.sd-bg-secondary:focus,a.sd-bg-secondary:hover{background-color:var(--sd-color-secondary-highlight) !important}.sd-bg-success{background-color:var(--sd-color-success) !important}.sd-bg-text-success{color:var(--sd-color-success-text) !important}button.sd-bg-success:focus,button.sd-bg-success:hover{background-color:var(--sd-color-success-highlight) !important}a.sd-bg-success:focus,a.sd-bg-success:hover{background-color:var(--sd-color-success-highlight) !important}.sd-bg-info{background-color:var(--sd-color-info) !important}.sd-bg-text-info{color:var(--sd-color-info-text) !important}button.sd-bg-info:focus,button.sd-bg-info:hover{background-color:var(--sd-color-info-highlight) !important}a.sd-bg-info:focus,a.sd-bg-info:hover{background-color:var(--sd-color-info-highlight) !important}.sd-bg-warning{background-color:var(--sd-color-warning) !important}.sd-bg-text-warning{color:var(--sd-color-warning-text) !important}button.sd-bg-warning:focus,button.sd-bg-warning:hover{background-color:var(--sd-color-warning-highlight) !important}a.sd-bg-warning:focus,a.sd-bg-warning:hover{background-color:var(--sd-color-warning-highlight) !important}.sd-bg-danger{background-color:var(--sd-color-danger) !important}.sd-bg-text-danger{color:var(--sd-color-danger-text) !important}button.sd-bg-danger:focus,button.sd-bg-danger:hover{background-color:var(--sd-color-danger-highlight) !important}a.sd-bg-danger:focus,a.sd-bg-danger:hover{background-color:var(--sd-color-danger-highlight) !important}.sd-bg-light{background-color:var(--sd-color-light) !important}.sd-bg-text-light{color:var(--sd-color-light-text) !important}button.sd-bg-light:focus,button.sd-bg-light:hover{background-color:var(--sd-color-light-highlight) !important}a.sd-bg-light:focus,a.sd-bg-light:hover{background-color:var(--sd-color-light-highlight) !important}.sd-bg-muted{background-color:var(--sd-color-muted) !important}.sd-bg-text-muted{color:var(--sd-color-muted-text) !important}button.sd-bg-muted:focus,button.sd-bg-muted:hover{background-color:var(--sd-color-muted-highlight) !important}a.sd-bg-muted:focus,a.sd-bg-muted:hover{background-color:var(--sd-color-muted-highlight) !important}.sd-bg-dark{background-color:var(--sd-color-dark) !important}.sd-bg-text-dark{color:var(--sd-color-dark-text) !important}button.sd-bg-dark:focus,button.sd-bg-dark:hover{background-color:var(--sd-color-dark-highlight) !important}a.sd-bg-dark:focus,a.sd-bg-dark:hover{background-color:var(--sd-color-dark-highlight) !important}.sd-bg-black{background-color:var(--sd-color-black) !important}.sd-bg-text-black{color:var(--sd-color-black-text) !important}button.sd-bg-black:focus,button.sd-bg-black:hover{background-color:var(--sd-color-black-highlight) !important}a.sd-bg-black:focus,a.sd-bg-black:hover{background-color:var(--sd-color-black-highlight) !important}.sd-bg-white{background-color:var(--sd-color-white) !important}.sd-bg-text-white{color:var(--sd-color-white-text) !important}button.sd-bg-white:focus,button.sd-bg-white:hover{background-color:var(--sd-color-white-highlight) !important}a.sd-bg-white:focus,a.sd-bg-white:hover{background-color:var(--sd-color-white-highlight) !important}.sd-text-primary,.sd-text-primary>p{color:var(--sd-color-primary) !important}a.sd-text-primary:focus,a.sd-text-primary:hover{color:var(--sd-color-primary-highlight) !important}.sd-text-secondary,.sd-text-secondary>p{color:var(--sd-color-secondary) !important}a.sd-text-secondary:focus,a.sd-text-secondary:hover{color:var(--sd-color-secondary-highlight) !important}.sd-text-success,.sd-text-success>p{color:var(--sd-color-success) !important}a.sd-text-success:focus,a.sd-text-success:hover{color:var(--sd-color-success-highlight) !important}.sd-text-info,.sd-text-info>p{color:var(--sd-color-info) !important}a.sd-text-info:focus,a.sd-text-info:hover{color:var(--sd-color-info-highlight) !important}.sd-text-warning,.sd-text-warning>p{color:var(--sd-color-warning) !important}a.sd-text-warning:focus,a.sd-text-warning:hover{color:var(--sd-color-warning-highlight) !important}.sd-text-danger,.sd-text-danger>p{color:var(--sd-color-danger) !important}a.sd-text-danger:focus,a.sd-text-danger:hover{color:var(--sd-color-danger-highlight) !important}.sd-text-light,.sd-text-light>p{color:var(--sd-color-light) !important}a.sd-text-light:focus,a.sd-text-light:hover{color:var(--sd-color-light-highlight) !important}.sd-text-muted,.sd-text-muted>p{color:var(--sd-color-muted) !important}a.sd-text-muted:focus,a.sd-text-muted:hover{color:var(--sd-color-muted-highlight) !important}.sd-text-dark,.sd-text-dark>p{color:var(--sd-color-dark) !important}a.sd-text-dark:focus,a.sd-text-dark:hover{color:var(--sd-color-dark-highlight) !important}.sd-text-black,.sd-text-black>p{color:var(--sd-color-black) !important}a.sd-text-black:focus,a.sd-text-black:hover{color:var(--sd-color-black-highlight) !important}.sd-text-white,.sd-text-white>p{color:var(--sd-color-white) !important}a.sd-text-white:focus,a.sd-text-white:hover{color:var(--sd-color-white-highlight) !important}.sd-outline-primary{border-color:var(--sd-color-primary) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-primary:focus,a.sd-outline-primary:hover{border-color:var(--sd-color-primary-highlight) !important}.sd-outline-secondary{border-color:var(--sd-color-secondary) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-secondary:focus,a.sd-outline-secondary:hover{border-color:var(--sd-color-secondary-highlight) !important}.sd-outline-success{border-color:var(--sd-color-success) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-success:focus,a.sd-outline-success:hover{border-color:var(--sd-color-success-highlight) !important}.sd-outline-info{border-color:var(--sd-color-info) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-info:focus,a.sd-outline-info:hover{border-color:var(--sd-color-info-highlight) !important}.sd-outline-warning{border-color:var(--sd-color-warning) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-warning:focus,a.sd-outline-warning:hover{border-color:var(--sd-color-warning-highlight) !important}.sd-outline-danger{border-color:var(--sd-color-danger) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-danger:focus,a.sd-outline-danger:hover{border-color:var(--sd-color-danger-highlight) !important}.sd-outline-light{border-color:var(--sd-color-light) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-light:focus,a.sd-outline-light:hover{border-color:var(--sd-color-light-highlight) !important}.sd-outline-muted{border-color:var(--sd-color-muted) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-muted:focus,a.sd-outline-muted:hover{border-color:var(--sd-color-muted-highlight) !important}.sd-outline-dark{border-color:var(--sd-color-dark) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-dark:focus,a.sd-outline-dark:hover{border-color:var(--sd-color-dark-highlight) !important}.sd-outline-black{border-color:var(--sd-color-black) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-black:focus,a.sd-outline-black:hover{border-color:var(--sd-color-black-highlight) !important}.sd-outline-white{border-color:var(--sd-color-white) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-white:focus,a.sd-outline-white:hover{border-color:var(--sd-color-white-highlight) !important}.sd-bg-transparent{background-color:transparent !important}.sd-outline-transparent{border-color:transparent !important}.sd-text-transparent{color:transparent !important}.sd-p-0{padding:0 !important}.sd-pt-0,.sd-py-0{padding-top:0 !important}.sd-pr-0,.sd-px-0{padding-right:0 !important}.sd-pb-0,.sd-py-0{padding-bottom:0 !important}.sd-pl-0,.sd-px-0{padding-left:0 !important}.sd-p-1{padding:.25rem !important}.sd-pt-1,.sd-py-1{padding-top:.25rem !important}.sd-pr-1,.sd-px-1{padding-right:.25rem !important}.sd-pb-1,.sd-py-1{padding-bottom:.25rem !important}.sd-pl-1,.sd-px-1{padding-left:.25rem !important}.sd-p-2{padding:.5rem !important}.sd-pt-2,.sd-py-2{padding-top:.5rem !important}.sd-pr-2,.sd-px-2{padding-right:.5rem !important}.sd-pb-2,.sd-py-2{padding-bottom:.5rem !important}.sd-pl-2,.sd-px-2{padding-left:.5rem !important}.sd-p-3{padding:1rem !important}.sd-pt-3,.sd-py-3{padding-top:1rem !important}.sd-pr-3,.sd-px-3{padding-right:1rem !important}.sd-pb-3,.sd-py-3{padding-bottom:1rem !important}.sd-pl-3,.sd-px-3{padding-left:1rem !important}.sd-p-4{padding:1.5rem !important}.sd-pt-4,.sd-py-4{padding-top:1.5rem !important}.sd-pr-4,.sd-px-4{padding-right:1.5rem !important}.sd-pb-4,.sd-py-4{padding-bottom:1.5rem !important}.sd-pl-4,.sd-px-4{padding-left:1.5rem !important}.sd-p-5{padding:3rem !important}.sd-pt-5,.sd-py-5{padding-top:3rem !important}.sd-pr-5,.sd-px-5{padding-right:3rem !important}.sd-pb-5,.sd-py-5{padding-bottom:3rem !important}.sd-pl-5,.sd-px-5{padding-left:3rem !important}.sd-m-auto{margin:auto !important}.sd-mt-auto,.sd-my-auto{margin-top:auto !important}.sd-mr-auto,.sd-mx-auto{margin-right:auto !important}.sd-mb-auto,.sd-my-auto{margin-bottom:auto !important}.sd-ml-auto,.sd-mx-auto{margin-left:auto !important}.sd-m-0{margin:0 !important}.sd-mt-0,.sd-my-0{margin-top:0 !important}.sd-mr-0,.sd-mx-0{margin-right:0 !important}.sd-mb-0,.sd-my-0{margin-bottom:0 !important}.sd-ml-0,.sd-mx-0{margin-left:0 !important}.sd-m-1{margin:.25rem !important}.sd-mt-1,.sd-my-1{margin-top:.25rem !important}.sd-mr-1,.sd-mx-1{margin-right:.25rem !important}.sd-mb-1,.sd-my-1{margin-bottom:.25rem !important}.sd-ml-1,.sd-mx-1{margin-left:.25rem !important}.sd-m-2{margin:.5rem !important}.sd-mt-2,.sd-my-2{margin-top:.5rem !important}.sd-mr-2,.sd-mx-2{margin-right:.5rem !important}.sd-mb-2,.sd-my-2{margin-bottom:.5rem !important}.sd-ml-2,.sd-mx-2{margin-left:.5rem !important}.sd-m-3{margin:1rem !important}.sd-mt-3,.sd-my-3{margin-top:1rem !important}.sd-mr-3,.sd-mx-3{margin-right:1rem !important}.sd-mb-3,.sd-my-3{margin-bottom:1rem !important}.sd-ml-3,.sd-mx-3{margin-left:1rem !important}.sd-m-4{margin:1.5rem !important}.sd-mt-4,.sd-my-4{margin-top:1.5rem !important}.sd-mr-4,.sd-mx-4{margin-right:1.5rem !important}.sd-mb-4,.sd-my-4{margin-bottom:1.5rem !important}.sd-ml-4,.sd-mx-4{margin-left:1.5rem !important}.sd-m-5{margin:3rem !important}.sd-mt-5,.sd-my-5{margin-top:3rem !important}.sd-mr-5,.sd-mx-5{margin-right:3rem !important}.sd-mb-5,.sd-my-5{margin-bottom:3rem !important}.sd-ml-5,.sd-mx-5{margin-left:3rem !important}.sd-w-25{width:25% !important}.sd-w-50{width:50% !important}.sd-w-75{width:75% !important}.sd-w-100{width:100% !important}.sd-w-auto{width:auto !important}.sd-h-25{height:25% !important}.sd-h-50{height:50% !important}.sd-h-75{height:75% !important}.sd-h-100{height:100% !important}.sd-h-auto{height:auto !important}.sd-d-none{display:none !important}.sd-d-inline{display:inline !important}.sd-d-inline-block{display:inline-block !important}.sd-d-block{display:block !important}.sd-d-grid{display:grid !important}.sd-d-flex-row{display:-ms-flexbox !important;display:flex !important;flex-direction:row !important}.sd-d-flex-column{display:-ms-flexbox !important;display:flex !important;flex-direction:column !important}.sd-d-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}@media(min-width: 576px){.sd-d-sm-none{display:none !important}.sd-d-sm-inline{display:inline !important}.sd-d-sm-inline-block{display:inline-block !important}.sd-d-sm-block{display:block !important}.sd-d-sm-grid{display:grid !important}.sd-d-sm-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-sm-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}@media(min-width: 768px){.sd-d-md-none{display:none !important}.sd-d-md-inline{display:inline !important}.sd-d-md-inline-block{display:inline-block !important}.sd-d-md-block{display:block !important}.sd-d-md-grid{display:grid !important}.sd-d-md-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-md-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}@media(min-width: 992px){.sd-d-lg-none{display:none !important}.sd-d-lg-inline{display:inline !important}.sd-d-lg-inline-block{display:inline-block !important}.sd-d-lg-block{display:block !important}.sd-d-lg-grid{display:grid !important}.sd-d-lg-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-lg-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}@media(min-width: 1200px){.sd-d-xl-none{display:none !important}.sd-d-xl-inline{display:inline !important}.sd-d-xl-inline-block{display:inline-block !important}.sd-d-xl-block{display:block !important}.sd-d-xl-grid{display:grid !important}.sd-d-xl-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-xl-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}.sd-align-major-start{justify-content:flex-start !important}.sd-align-major-end{justify-content:flex-end !important}.sd-align-major-center{justify-content:center !important}.sd-align-major-justify{justify-content:space-between !important}.sd-align-major-spaced{justify-content:space-evenly !important}.sd-align-minor-start{align-items:flex-start !important}.sd-align-minor-end{align-items:flex-end !important}.sd-align-minor-center{align-items:center !important}.sd-align-minor-stretch{align-items:stretch !important}.sd-text-justify{text-align:justify !important}.sd-text-left{text-align:left !important}.sd-text-right{text-align:right !important}.sd-text-center{text-align:center !important}.sd-font-weight-light{font-weight:300 !important}.sd-font-weight-lighter{font-weight:lighter !important}.sd-font-weight-normal{font-weight:400 !important}.sd-font-weight-bold{font-weight:700 !important}.sd-font-weight-bolder{font-weight:bolder !important}.sd-font-italic{font-style:italic !important}.sd-text-decoration-none{text-decoration:none !important}.sd-text-lowercase{text-transform:lowercase !important}.sd-text-uppercase{text-transform:uppercase !important}.sd-text-capitalize{text-transform:capitalize !important}.sd-text-wrap{white-space:normal !important}.sd-text-nowrap{white-space:nowrap !important}.sd-text-truncate{overflow:hidden;text-overflow:ellipsis;white-space:nowrap}.sd-fs-1,.sd-fs-1>p{font-size:calc(1.375rem + 1.5vw) !important;line-height:unset !important}.sd-fs-2,.sd-fs-2>p{font-size:calc(1.325rem + 0.9vw) !important;line-height:unset !important}.sd-fs-3,.sd-fs-3>p{font-size:calc(1.3rem + 0.6vw) !important;line-height:unset !important}.sd-fs-4,.sd-fs-4>p{font-size:calc(1.275rem + 0.3vw) !important;line-height:unset !important}.sd-fs-5,.sd-fs-5>p{font-size:1.25rem !important;line-height:unset !important}.sd-fs-6,.sd-fs-6>p{font-size:1rem !important;line-height:unset !important}.sd-border-0{border:0 solid !important}.sd-border-top-0{border-top:0 solid !important}.sd-border-bottom-0{border-bottom:0 solid !important}.sd-border-right-0{border-right:0 solid !important}.sd-border-left-0{border-left:0 solid !important}.sd-border-1{border:1px solid !important}.sd-border-top-1{border-top:1px solid !important}.sd-border-bottom-1{border-bottom:1px solid !important}.sd-border-right-1{border-right:1px solid !important}.sd-border-left-1{border-left:1px solid !important}.sd-border-2{border:2px solid !important}.sd-border-top-2{border-top:2px solid !important}.sd-border-bottom-2{border-bottom:2px solid !important}.sd-border-right-2{border-right:2px solid !important}.sd-border-left-2{border-left:2px solid !important}.sd-border-3{border:3px solid !important}.sd-border-top-3{border-top:3px solid !important}.sd-border-bottom-3{border-bottom:3px solid !important}.sd-border-right-3{border-right:3px solid !important}.sd-border-left-3{border-left:3px solid !important}.sd-border-4{border:4px solid !important}.sd-border-top-4{border-top:4px solid !important}.sd-border-bottom-4{border-bottom:4px solid !important}.sd-border-right-4{border-right:4px solid !important}.sd-border-left-4{border-left:4px solid !important}.sd-border-5{border:5px solid !important}.sd-border-top-5{border-top:5px solid !important}.sd-border-bottom-5{border-bottom:5px solid !important}.sd-border-right-5{border-right:5px solid !important}.sd-border-left-5{border-left:5px solid !important}.sd-rounded-0{border-radius:0 !important}.sd-rounded-1{border-radius:.2rem !important}.sd-rounded-2{border-radius:.3rem !important}.sd-rounded-3{border-radius:.5rem !important}.sd-rounded-pill{border-radius:50rem !important}.sd-rounded-circle{border-radius:50% !important}.shadow-none{box-shadow:none !important}.sd-shadow-sm{box-shadow:0 .125rem .25rem var(--sd-color-shadow) !important}.sd-shadow-md{box-shadow:0 .5rem 1rem var(--sd-color-shadow) !important}.sd-shadow-lg{box-shadow:0 1rem 3rem var(--sd-color-shadow) !important}@keyframes sd-slide-from-left{0%{transform:translateX(-100%)}100%{transform:translateX(0)}}@keyframes sd-slide-from-right{0%{transform:translateX(200%)}100%{transform:translateX(0)}}@keyframes sd-grow100{0%{transform:scale(0);opacity:.5}100%{transform:scale(1);opacity:1}}@keyframes sd-grow50{0%{transform:scale(0.5);opacity:.5}100%{transform:scale(1);opacity:1}}@keyframes sd-grow50-rot20{0%{transform:scale(0.5) rotateZ(-20deg);opacity:.5}75%{transform:scale(1) rotateZ(5deg);opacity:1}95%{transform:scale(1) rotateZ(-1deg);opacity:1}100%{transform:scale(1) rotateZ(0);opacity:1}}.sd-animate-slide-from-left{animation:1s ease-out 0s 1 normal none running sd-slide-from-left}.sd-animate-slide-from-right{animation:1s ease-out 0s 1 normal none running sd-slide-from-right}.sd-animate-grow100{animation:1s ease-out 0s 1 normal none running sd-grow100}.sd-animate-grow50{animation:1s ease-out 0s 1 normal none running sd-grow50}.sd-animate-grow50-rot20{animation:1s ease-out 0s 1 normal none running sd-grow50-rot20}.sd-badge{display:inline-block;padding:.35em .65em;font-size:.75em;font-weight:700;line-height:1;text-align:center;white-space:nowrap;vertical-align:baseline;border-radius:.25rem}.sd-badge:empty{display:none}a.sd-badge{text-decoration:none}.sd-btn .sd-badge{position:relative;top:-1px}.sd-btn{background-color:transparent;border:1px solid transparent;border-radius:.25rem;cursor:pointer;display:inline-block;font-weight:400;font-size:1rem;line-height:1.5;padding:.375rem .75rem;text-align:center;text-decoration:none;transition:color .15s ease-in-out,background-color .15s ease-in-out,border-color .15s ease-in-out,box-shadow .15s ease-in-out;vertical-align:middle;user-select:none;-moz-user-select:none;-ms-user-select:none;-webkit-user-select:none}.sd-btn:hover{text-decoration:none}@media(prefers-reduced-motion: reduce){.sd-btn{transition:none}}.sd-btn-primary,.sd-btn-outline-primary:hover,.sd-btn-outline-primary:focus{color:var(--sd-color-primary-text) !important;background-color:var(--sd-color-primary) !important;border-color:var(--sd-color-primary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-primary:hover,.sd-btn-primary:focus{color:var(--sd-color-primary-text) !important;background-color:var(--sd-color-primary-highlight) !important;border-color:var(--sd-color-primary-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-primary{color:var(--sd-color-primary) !important;border-color:var(--sd-color-primary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-secondary,.sd-btn-outline-secondary:hover,.sd-btn-outline-secondary:focus{color:var(--sd-color-secondary-text) !important;background-color:var(--sd-color-secondary) !important;border-color:var(--sd-color-secondary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-secondary:hover,.sd-btn-secondary:focus{color:var(--sd-color-secondary-text) !important;background-color:var(--sd-color-secondary-highlight) !important;border-color:var(--sd-color-secondary-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-secondary{color:var(--sd-color-secondary) !important;border-color:var(--sd-color-secondary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-success,.sd-btn-outline-success:hover,.sd-btn-outline-success:focus{color:var(--sd-color-success-text) !important;background-color:var(--sd-color-success) !important;border-color:var(--sd-color-success) !important;border-width:1px !important;border-style:solid !important}.sd-btn-success:hover,.sd-btn-success:focus{color:var(--sd-color-success-text) !important;background-color:var(--sd-color-success-highlight) !important;border-color:var(--sd-color-success-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-success{color:var(--sd-color-success) !important;border-color:var(--sd-color-success) !important;border-width:1px !important;border-style:solid !important}.sd-btn-info,.sd-btn-outline-info:hover,.sd-btn-outline-info:focus{color:var(--sd-color-info-text) !important;background-color:var(--sd-color-info) !important;border-color:var(--sd-color-info) !important;border-width:1px !important;border-style:solid !important}.sd-btn-info:hover,.sd-btn-info:focus{color:var(--sd-color-info-text) !important;background-color:var(--sd-color-info-highlight) !important;border-color:var(--sd-color-info-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-info{color:var(--sd-color-info) !important;border-color:var(--sd-color-info) !important;border-width:1px !important;border-style:solid !important}.sd-btn-warning,.sd-btn-outline-warning:hover,.sd-btn-outline-warning:focus{color:var(--sd-color-warning-text) !important;background-color:var(--sd-color-warning) !important;border-color:var(--sd-color-warning) !important;border-width:1px !important;border-style:solid !important}.sd-btn-warning:hover,.sd-btn-warning:focus{color:var(--sd-color-warning-text) !important;background-color:var(--sd-color-warning-highlight) !important;border-color:var(--sd-color-warning-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-warning{color:var(--sd-color-warning) !important;border-color:var(--sd-color-warning) !important;border-width:1px !important;border-style:solid !important}.sd-btn-danger,.sd-btn-outline-danger:hover,.sd-btn-outline-danger:focus{color:var(--sd-color-danger-text) !important;background-color:var(--sd-color-danger) !important;border-color:var(--sd-color-danger) !important;border-width:1px !important;border-style:solid !important}.sd-btn-danger:hover,.sd-btn-danger:focus{color:var(--sd-color-danger-text) !important;background-color:var(--sd-color-danger-highlight) !important;border-color:var(--sd-color-danger-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-danger{color:var(--sd-color-danger) !important;border-color:var(--sd-color-danger) !important;border-width:1px !important;border-style:solid !important}.sd-btn-light,.sd-btn-outline-light:hover,.sd-btn-outline-light:focus{color:var(--sd-color-light-text) !important;background-color:var(--sd-color-light) !important;border-color:var(--sd-color-light) !important;border-width:1px !important;border-style:solid !important}.sd-btn-light:hover,.sd-btn-light:focus{color:var(--sd-color-light-text) !important;background-color:var(--sd-color-light-highlight) !important;border-color:var(--sd-color-light-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-light{color:var(--sd-color-light) !important;border-color:var(--sd-color-light) !important;border-width:1px !important;border-style:solid !important}.sd-btn-muted,.sd-btn-outline-muted:hover,.sd-btn-outline-muted:focus{color:var(--sd-color-muted-text) !important;background-color:var(--sd-color-muted) !important;border-color:var(--sd-color-muted) !important;border-width:1px !important;border-style:solid !important}.sd-btn-muted:hover,.sd-btn-muted:focus{color:var(--sd-color-muted-text) !important;background-color:var(--sd-color-muted-highlight) !important;border-color:var(--sd-color-muted-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-muted{color:var(--sd-color-muted) !important;border-color:var(--sd-color-muted) !important;border-width:1px !important;border-style:solid !important}.sd-btn-dark,.sd-btn-outline-dark:hover,.sd-btn-outline-dark:focus{color:var(--sd-color-dark-text) !important;background-color:var(--sd-color-dark) !important;border-color:var(--sd-color-dark) !important;border-width:1px !important;border-style:solid !important}.sd-btn-dark:hover,.sd-btn-dark:focus{color:var(--sd-color-dark-text) !important;background-color:var(--sd-color-dark-highlight) !important;border-color:var(--sd-color-dark-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-dark{color:var(--sd-color-dark) !important;border-color:var(--sd-color-dark) !important;border-width:1px !important;border-style:solid !important}.sd-btn-black,.sd-btn-outline-black:hover,.sd-btn-outline-black:focus{color:var(--sd-color-black-text) !important;background-color:var(--sd-color-black) !important;border-color:var(--sd-color-black) !important;border-width:1px !important;border-style:solid !important}.sd-btn-black:hover,.sd-btn-black:focus{color:var(--sd-color-black-text) !important;background-color:var(--sd-color-black-highlight) !important;border-color:var(--sd-color-black-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-black{color:var(--sd-color-black) !important;border-color:var(--sd-color-black) !important;border-width:1px !important;border-style:solid !important}.sd-btn-white,.sd-btn-outline-white:hover,.sd-btn-outline-white:focus{color:var(--sd-color-white-text) !important;background-color:var(--sd-color-white) !important;border-color:var(--sd-color-white) !important;border-width:1px !important;border-style:solid !important}.sd-btn-white:hover,.sd-btn-white:focus{color:var(--sd-color-white-text) !important;background-color:var(--sd-color-white-highlight) !important;border-color:var(--sd-color-white-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-white{color:var(--sd-color-white) !important;border-color:var(--sd-color-white) !important;border-width:1px !important;border-style:solid !important}.sd-stretched-link::after{position:absolute;top:0;right:0;bottom:0;left:0;z-index:1;content:""}.sd-hide-link-text{font-size:0}.sd-octicon,.sd-material-icon{display:inline-block;fill:currentColor;vertical-align:middle}.sd-avatar-xs{border-radius:50%;object-fit:cover;object-position:center;width:1rem;height:1rem}.sd-avatar-sm{border-radius:50%;object-fit:cover;object-position:center;width:3rem;height:3rem}.sd-avatar-md{border-radius:50%;object-fit:cover;object-position:center;width:5rem;height:5rem}.sd-avatar-lg{border-radius:50%;object-fit:cover;object-position:center;width:7rem;height:7rem}.sd-avatar-xl{border-radius:50%;object-fit:cover;object-position:center;width:10rem;height:10rem}.sd-avatar-inherit{border-radius:50%;object-fit:cover;object-position:center;width:inherit;height:inherit}.sd-avatar-initial{border-radius:50%;object-fit:cover;object-position:center;width:initial;height:initial}.sd-card{background-clip:border-box;background-color:var(--sd-color-card-background);border:1px solid var(--sd-color-card-border);border-radius:.25rem;color:var(--sd-color-card-text);display:-ms-flexbox;display:flex;-ms-flex-direction:column;flex-direction:column;min-width:0;position:relative;word-wrap:break-word}.sd-card>hr{margin-left:0;margin-right:0}.sd-card-hover:hover{border-color:var(--sd-color-card-border-hover);transform:scale(1.01)}.sd-card-body{-ms-flex:1 1 auto;flex:1 1 auto;padding:1rem 1rem}.sd-card-title{margin-bottom:.5rem}.sd-card-subtitle{margin-top:-0.25rem;margin-bottom:0}.sd-card-text:last-child{margin-bottom:0}.sd-card-link:hover{text-decoration:none}.sd-card-link+.card-link{margin-left:1rem}.sd-card-header{padding:.5rem 1rem;margin-bottom:0;background-color:var(--sd-color-card-header);border-bottom:1px solid var(--sd-color-card-border)}.sd-card-header:first-child{border-radius:calc(0.25rem - 1px) calc(0.25rem - 1px) 0 0}.sd-card-footer{padding:.5rem 1rem;background-color:var(--sd-color-card-footer);border-top:1px solid var(--sd-color-card-border)}.sd-card-footer:last-child{border-radius:0 0 calc(0.25rem - 1px) calc(0.25rem - 1px)}.sd-card-header-tabs{margin-right:-0.5rem;margin-bottom:-0.5rem;margin-left:-0.5rem;border-bottom:0}.sd-card-header-pills{margin-right:-0.5rem;margin-left:-0.5rem}.sd-card-img-overlay{position:absolute;top:0;right:0;bottom:0;left:0;padding:1rem;border-radius:calc(0.25rem - 1px)}.sd-card-img,.sd-card-img-bottom,.sd-card-img-top{width:100%}.sd-card-img,.sd-card-img-top{border-top-left-radius:calc(0.25rem - 1px);border-top-right-radius:calc(0.25rem - 1px)}.sd-card-img,.sd-card-img-bottom{border-bottom-left-radius:calc(0.25rem - 1px);border-bottom-right-radius:calc(0.25rem - 1px)}.sd-cards-carousel{width:100%;display:flex;flex-wrap:nowrap;-ms-flex-direction:row;flex-direction:row;overflow-x:hidden;scroll-snap-type:x mandatory}.sd-cards-carousel.sd-show-scrollbar{overflow-x:auto}.sd-cards-carousel:hover,.sd-cards-carousel:focus{overflow-x:auto}.sd-cards-carousel>.sd-card{flex-shrink:0;scroll-snap-align:start}.sd-cards-carousel>.sd-card:not(:last-child){margin-right:3px}.sd-card-cols-1>.sd-card{width:90%}.sd-card-cols-2>.sd-card{width:45%}.sd-card-cols-3>.sd-card{width:30%}.sd-card-cols-4>.sd-card{width:22.5%}.sd-card-cols-5>.sd-card{width:18%}.sd-card-cols-6>.sd-card{width:15%}.sd-card-cols-7>.sd-card{width:12.8571428571%}.sd-card-cols-8>.sd-card{width:11.25%}.sd-card-cols-9>.sd-card{width:10%}.sd-card-cols-10>.sd-card{width:9%}.sd-card-cols-11>.sd-card{width:8.1818181818%}.sd-card-cols-12>.sd-card{width:7.5%}.sd-container,.sd-container-fluid,.sd-container-lg,.sd-container-md,.sd-container-sm,.sd-container-xl{margin-left:auto;margin-right:auto;padding-left:var(--sd-gutter-x, 0.75rem);padding-right:var(--sd-gutter-x, 0.75rem);width:100%}@media(min-width: 576px){.sd-container-sm,.sd-container{max-width:540px}}@media(min-width: 768px){.sd-container-md,.sd-container-sm,.sd-container{max-width:720px}}@media(min-width: 992px){.sd-container-lg,.sd-container-md,.sd-container-sm,.sd-container{max-width:960px}}@media(min-width: 1200px){.sd-container-xl,.sd-container-lg,.sd-container-md,.sd-container-sm,.sd-container{max-width:1140px}}.sd-row{--sd-gutter-x: 1.5rem;--sd-gutter-y: 0;display:-ms-flexbox;display:flex;-ms-flex-wrap:wrap;flex-wrap:wrap;margin-top:calc(var(--sd-gutter-y) * -1);margin-right:calc(var(--sd-gutter-x) * -0.5);margin-left:calc(var(--sd-gutter-x) * -0.5)}.sd-row>*{box-sizing:border-box;flex-shrink:0;width:100%;max-width:100%;padding-right:calc(var(--sd-gutter-x) * 0.5);padding-left:calc(var(--sd-gutter-x) * 0.5);margin-top:var(--sd-gutter-y)}.sd-col{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-auto>*{flex:0 0 auto;width:auto}.sd-row-cols-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}@media(min-width: 576px){.sd-col-sm{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-sm-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-sm-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-sm-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-sm-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-sm-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-sm-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-sm-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-sm-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-sm-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-sm-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-sm-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-sm-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-sm-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}@media(min-width: 768px){.sd-col-md{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-md-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-md-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-md-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-md-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-md-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-md-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-md-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-md-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-md-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-md-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-md-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-md-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-md-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}@media(min-width: 992px){.sd-col-lg{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-lg-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-lg-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-lg-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-lg-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-lg-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-lg-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-lg-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-lg-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-lg-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-lg-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-lg-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-lg-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-lg-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}@media(min-width: 1200px){.sd-col-xl{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-xl-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-xl-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-xl-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-xl-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-xl-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-xl-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-xl-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-xl-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-xl-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-xl-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-xl-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-xl-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-xl-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}.sd-col-auto{flex:0 0 auto;-ms-flex:0 0 auto;width:auto}.sd-col-1{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}.sd-col-2{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-col-3{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-col-4{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-col-5{flex:0 0 auto;-ms-flex:0 0 auto;width:41.6666666667%}.sd-col-6{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-col-7{flex:0 0 auto;-ms-flex:0 0 auto;width:58.3333333333%}.sd-col-8{flex:0 0 auto;-ms-flex:0 0 auto;width:66.6666666667%}.sd-col-9{flex:0 0 auto;-ms-flex:0 0 auto;width:75%}.sd-col-10{flex:0 0 auto;-ms-flex:0 0 auto;width:83.3333333333%}.sd-col-11{flex:0 0 auto;-ms-flex:0 0 auto;width:91.6666666667%}.sd-col-12{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-g-0,.sd-gy-0{--sd-gutter-y: 0}.sd-g-0,.sd-gx-0{--sd-gutter-x: 0}.sd-g-1,.sd-gy-1{--sd-gutter-y: 0.25rem}.sd-g-1,.sd-gx-1{--sd-gutter-x: 0.25rem}.sd-g-2,.sd-gy-2{--sd-gutter-y: 0.5rem}.sd-g-2,.sd-gx-2{--sd-gutter-x: 0.5rem}.sd-g-3,.sd-gy-3{--sd-gutter-y: 1rem}.sd-g-3,.sd-gx-3{--sd-gutter-x: 1rem}.sd-g-4,.sd-gy-4{--sd-gutter-y: 1.5rem}.sd-g-4,.sd-gx-4{--sd-gutter-x: 1.5rem}.sd-g-5,.sd-gy-5{--sd-gutter-y: 3rem}.sd-g-5,.sd-gx-5{--sd-gutter-x: 3rem}@media(min-width: 576px){.sd-col-sm-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-sm-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-sm-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-sm-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-sm-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-sm-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-sm-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-sm-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-sm-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-sm-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-sm-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-sm-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-sm-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-sm-0,.sd-gy-sm-0{--sd-gutter-y: 0}.sd-g-sm-0,.sd-gx-sm-0{--sd-gutter-x: 0}.sd-g-sm-1,.sd-gy-sm-1{--sd-gutter-y: 0.25rem}.sd-g-sm-1,.sd-gx-sm-1{--sd-gutter-x: 0.25rem}.sd-g-sm-2,.sd-gy-sm-2{--sd-gutter-y: 0.5rem}.sd-g-sm-2,.sd-gx-sm-2{--sd-gutter-x: 0.5rem}.sd-g-sm-3,.sd-gy-sm-3{--sd-gutter-y: 1rem}.sd-g-sm-3,.sd-gx-sm-3{--sd-gutter-x: 1rem}.sd-g-sm-4,.sd-gy-sm-4{--sd-gutter-y: 1.5rem}.sd-g-sm-4,.sd-gx-sm-4{--sd-gutter-x: 1.5rem}.sd-g-sm-5,.sd-gy-sm-5{--sd-gutter-y: 3rem}.sd-g-sm-5,.sd-gx-sm-5{--sd-gutter-x: 3rem}}@media(min-width: 768px){.sd-col-md-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-md-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-md-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-md-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-md-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-md-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-md-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-md-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-md-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-md-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-md-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-md-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-md-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-md-0,.sd-gy-md-0{--sd-gutter-y: 0}.sd-g-md-0,.sd-gx-md-0{--sd-gutter-x: 0}.sd-g-md-1,.sd-gy-md-1{--sd-gutter-y: 0.25rem}.sd-g-md-1,.sd-gx-md-1{--sd-gutter-x: 0.25rem}.sd-g-md-2,.sd-gy-md-2{--sd-gutter-y: 0.5rem}.sd-g-md-2,.sd-gx-md-2{--sd-gutter-x: 0.5rem}.sd-g-md-3,.sd-gy-md-3{--sd-gutter-y: 1rem}.sd-g-md-3,.sd-gx-md-3{--sd-gutter-x: 1rem}.sd-g-md-4,.sd-gy-md-4{--sd-gutter-y: 1.5rem}.sd-g-md-4,.sd-gx-md-4{--sd-gutter-x: 1.5rem}.sd-g-md-5,.sd-gy-md-5{--sd-gutter-y: 3rem}.sd-g-md-5,.sd-gx-md-5{--sd-gutter-x: 3rem}}@media(min-width: 992px){.sd-col-lg-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-lg-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-lg-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-lg-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-lg-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-lg-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-lg-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-lg-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-lg-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-lg-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-lg-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-lg-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-lg-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-lg-0,.sd-gy-lg-0{--sd-gutter-y: 0}.sd-g-lg-0,.sd-gx-lg-0{--sd-gutter-x: 0}.sd-g-lg-1,.sd-gy-lg-1{--sd-gutter-y: 0.25rem}.sd-g-lg-1,.sd-gx-lg-1{--sd-gutter-x: 0.25rem}.sd-g-lg-2,.sd-gy-lg-2{--sd-gutter-y: 0.5rem}.sd-g-lg-2,.sd-gx-lg-2{--sd-gutter-x: 0.5rem}.sd-g-lg-3,.sd-gy-lg-3{--sd-gutter-y: 1rem}.sd-g-lg-3,.sd-gx-lg-3{--sd-gutter-x: 1rem}.sd-g-lg-4,.sd-gy-lg-4{--sd-gutter-y: 1.5rem}.sd-g-lg-4,.sd-gx-lg-4{--sd-gutter-x: 1.5rem}.sd-g-lg-5,.sd-gy-lg-5{--sd-gutter-y: 3rem}.sd-g-lg-5,.sd-gx-lg-5{--sd-gutter-x: 3rem}}@media(min-width: 1200px){.sd-col-xl-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-xl-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-xl-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-xl-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-xl-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-xl-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-xl-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-xl-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-xl-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-xl-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-xl-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-xl-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-xl-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-xl-0,.sd-gy-xl-0{--sd-gutter-y: 0}.sd-g-xl-0,.sd-gx-xl-0{--sd-gutter-x: 0}.sd-g-xl-1,.sd-gy-xl-1{--sd-gutter-y: 0.25rem}.sd-g-xl-1,.sd-gx-xl-1{--sd-gutter-x: 0.25rem}.sd-g-xl-2,.sd-gy-xl-2{--sd-gutter-y: 0.5rem}.sd-g-xl-2,.sd-gx-xl-2{--sd-gutter-x: 0.5rem}.sd-g-xl-3,.sd-gy-xl-3{--sd-gutter-y: 1rem}.sd-g-xl-3,.sd-gx-xl-3{--sd-gutter-x: 1rem}.sd-g-xl-4,.sd-gy-xl-4{--sd-gutter-y: 1.5rem}.sd-g-xl-4,.sd-gx-xl-4{--sd-gutter-x: 1.5rem}.sd-g-xl-5,.sd-gy-xl-5{--sd-gutter-y: 3rem}.sd-g-xl-5,.sd-gx-xl-5{--sd-gutter-x: 3rem}}.sd-flex-row-reverse{flex-direction:row-reverse !important}details.sd-dropdown{position:relative;font-size:var(--sd-fontsize-dropdown)}details.sd-dropdown:hover{cursor:pointer}details.sd-dropdown .sd-summary-content{cursor:default}details.sd-dropdown summary.sd-summary-title{padding:.5em .6em .5em 1em;font-size:var(--sd-fontsize-dropdown-title);font-weight:var(--sd-fontweight-dropdown-title);user-select:none;-moz-user-select:none;-ms-user-select:none;-webkit-user-select:none;list-style:none;display:inline-flex;justify-content:space-between}details.sd-dropdown summary.sd-summary-title::-webkit-details-marker{display:none}details.sd-dropdown summary.sd-summary-title:focus{outline:none}details.sd-dropdown summary.sd-summary-title .sd-summary-icon{margin-right:.6em;display:inline-flex;align-items:center}details.sd-dropdown summary.sd-summary-title .sd-summary-icon svg{opacity:.8}details.sd-dropdown summary.sd-summary-title .sd-summary-text{flex-grow:1;line-height:1.5;padding-right:.5rem}details.sd-dropdown summary.sd-summary-title .sd-summary-state-marker{pointer-events:none;display:inline-flex;align-items:center}details.sd-dropdown summary.sd-summary-title .sd-summary-state-marker svg{opacity:.6}details.sd-dropdown summary.sd-summary-title:hover .sd-summary-state-marker svg{opacity:1;transform:scale(1.1)}details.sd-dropdown[open] summary .sd-octicon.no-title{visibility:hidden}details.sd-dropdown .sd-summary-chevron-right{transition:.25s}details.sd-dropdown[open]>.sd-summary-title .sd-summary-chevron-right{transform:rotate(90deg)}details.sd-dropdown[open]>.sd-summary-title .sd-summary-chevron-down{transform:rotate(180deg)}details.sd-dropdown:not([open]).sd-card{border:none}details.sd-dropdown:not([open])>.sd-card-header{border:1px solid var(--sd-color-card-border);border-radius:.25rem}details.sd-dropdown.sd-fade-in[open] summary~*{-moz-animation:sd-fade-in .5s ease-in-out;-webkit-animation:sd-fade-in .5s ease-in-out;animation:sd-fade-in .5s ease-in-out}details.sd-dropdown.sd-fade-in-slide-down[open] summary~*{-moz-animation:sd-fade-in .5s ease-in-out,sd-slide-down .5s ease-in-out;-webkit-animation:sd-fade-in .5s ease-in-out,sd-slide-down .5s ease-in-out;animation:sd-fade-in .5s ease-in-out,sd-slide-down .5s ease-in-out}.sd-col>.sd-dropdown{width:100%}.sd-summary-content>.sd-tab-set:first-child{margin-top:0}@keyframes sd-fade-in{0%{opacity:0}100%{opacity:1}}@keyframes sd-slide-down{0%{transform:translate(0, -10px)}100%{transform:translate(0, 0)}}.sd-tab-set{border-radius:.125rem;display:flex;flex-wrap:wrap;margin:1em 0;position:relative}.sd-tab-set>input{opacity:0;position:absolute}.sd-tab-set>input:checked+label{border-color:var(--sd-color-tabs-underline-active);color:var(--sd-color-tabs-label-active)}.sd-tab-set>input:checked+label+.sd-tab-content{display:block}.sd-tab-set>input:not(:checked)+label:hover{color:var(--sd-color-tabs-label-hover);border-color:var(--sd-color-tabs-underline-hover)}.sd-tab-set>input:focus+label{outline-style:auto}.sd-tab-set>input:not(.focus-visible)+label{outline:none;-webkit-tap-highlight-color:transparent}.sd-tab-set>label{border-bottom:.125rem solid transparent;margin-bottom:0;color:var(--sd-color-tabs-label-inactive);border-color:var(--sd-color-tabs-underline-inactive);cursor:pointer;font-size:var(--sd-fontsize-tabs-label);font-weight:700;padding:1em 1.25em .5em;transition:color 250ms;width:auto;z-index:1}html .sd-tab-set>label:hover{color:var(--sd-color-tabs-label-active)}.sd-col>.sd-tab-set{width:100%}.sd-tab-content{box-shadow:0 -0.0625rem var(--sd-color-tabs-overline),0 .0625rem var(--sd-color-tabs-underline);display:none;order:99;padding-bottom:.75rem;padding-top:.75rem;width:100%}.sd-tab-content>:first-child{margin-top:0 !important}.sd-tab-content>:last-child{margin-bottom:0 !important}.sd-tab-content>.sd-tab-set{margin:0}.sd-sphinx-override,.sd-sphinx-override *{-moz-box-sizing:border-box;-webkit-box-sizing:border-box;box-sizing:border-box}.sd-sphinx-override p{margin-top:0}:root{--sd-color-primary: #0071bc;--sd-color-secondary: #6c757d;--sd-color-success: #28a745;--sd-color-info: #17a2b8;--sd-color-warning: #f0b37e;--sd-color-danger: #dc3545;--sd-color-light: #f8f9fa;--sd-color-muted: #6c757d;--sd-color-dark: #212529;--sd-color-black: black;--sd-color-white: white;--sd-color-primary-highlight: #0060a0;--sd-color-secondary-highlight: #5c636a;--sd-color-success-highlight: #228e3b;--sd-color-info-highlight: #148a9c;--sd-color-warning-highlight: #cc986b;--sd-color-danger-highlight: #bb2d3b;--sd-color-light-highlight: #d3d4d5;--sd-color-muted-highlight: #5c636a;--sd-color-dark-highlight: #1c1f23;--sd-color-black-highlight: black;--sd-color-white-highlight: #d9d9d9;--sd-color-primary-bg: rgba(0, 113, 188, 0.2);--sd-color-secondary-bg: rgba(108, 117, 125, 0.2);--sd-color-success-bg: rgba(40, 167, 69, 0.2);--sd-color-info-bg: rgba(23, 162, 184, 0.2);--sd-color-warning-bg: rgba(240, 179, 126, 0.2);--sd-color-danger-bg: rgba(220, 53, 69, 0.2);--sd-color-light-bg: rgba(248, 249, 250, 0.2);--sd-color-muted-bg: rgba(108, 117, 125, 0.2);--sd-color-dark-bg: rgba(33, 37, 41, 0.2);--sd-color-black-bg: rgba(0, 0, 0, 0.2);--sd-color-white-bg: rgba(255, 255, 255, 0.2);--sd-color-primary-text: #fff;--sd-color-secondary-text: #fff;--sd-color-success-text: #fff;--sd-color-info-text: #fff;--sd-color-warning-text: #212529;--sd-color-danger-text: #fff;--sd-color-light-text: #212529;--sd-color-muted-text: #fff;--sd-color-dark-text: #fff;--sd-color-black-text: #fff;--sd-color-white-text: #212529;--sd-color-shadow: rgba(0, 0, 0, 0.15);--sd-color-card-border: rgba(0, 0, 0, 0.125);--sd-color-card-border-hover: hsla(231, 99%, 66%, 1);--sd-color-card-background: transparent;--sd-color-card-text: inherit;--sd-color-card-header: transparent;--sd-color-card-footer: transparent;--sd-color-tabs-label-active: hsla(231, 99%, 66%, 1);--sd-color-tabs-label-hover: hsla(231, 99%, 66%, 1);--sd-color-tabs-label-inactive: hsl(0, 0%, 66%);--sd-color-tabs-underline-active: hsla(231, 99%, 66%, 1);--sd-color-tabs-underline-hover: rgba(178, 206, 245, 0.62);--sd-color-tabs-underline-inactive: transparent;--sd-color-tabs-overline: rgb(222, 222, 222);--sd-color-tabs-underline: rgb(222, 222, 222);--sd-fontsize-tabs-label: 1rem;--sd-fontsize-dropdown: inherit;--sd-fontsize-dropdown-title: 1rem;--sd-fontweight-dropdown-title: 700} _static/0000775000175000017500000000000014744715212012707 5ustar jfpiollejfpiolle_static/styles/0000775000175000017500000000000014744715206014235 5ustar jfpiollejfpiolle_static/styles/sphinx-book-theme.css.map0000664000175000017500000010171314632365026021064 0ustar jfpiollejfpiolle{"version":3,"file":"styles/sphinx-book-theme.css","mappings":"AAAA;;;;;;;EAAA,CC0CA,6CAGE,yBAA0B,CAG1B,6BAA8B,CAKhC,uBAEE,gCAAyC,CAEzC,2BAA4B,CAG9B,sBAEE,2BAA4B,CAG5B,gCAAyC,CAEzC,8BAA+B,CChEjC,KAIE,wBAOF,yBAGE,SAEA,MAAK,CAJL,kBAGA,MAFA,OAGA,CAYF,gBACE,aAEA,aAHF,WAII,wBAKJ,SAEI,uBAPA,CC9BF,6JAME,6BAIF,kDAEE,gBAKJ,kBACE,cACA,oBACA,eAGF,MACE,kBC1BF,aAEI,qBAEE,YADA,gBACA,CAEA,yCACE,cAEA,4CACE,cAEA,eAAc,CADd,iBACA,CAIJ,iCACE,cAGA,kDACE,aAKJ,gCACE,sBAIF,wBAEE,kBADA,cACA,CAEF,gGAIE,kBACA,WAGF,2BACE,mBAGF,yBACE,qBAGF,kCACE,aAIF,8GAGE,YAGF,6BACE,eAGF,mCACE,qBACA,cACA,gDACE,wBACA,+BACA,0BACA,kDACE,+BAEF,mDACE,4BAEF,qDACE,aAOR,4BACE,wBC3FN,wBACE,+CACA,WCFF,qBAEE,qBCFF,2CAME,WAAU,CAFV,iBAFA,SAIA,CAEA,yBARF,2CAUI,qDAGF,uDAEE,kBADA,kBACA,CACA,wBAHF,uDAKI,kBADA,kBACA,EAKF,8IACE,+CCNJ,wBADF,qCAEI,sBAEF,wBAJF,qCAKI,iBAMF,yBADF,uCAEI,cAEF,wBAJF,uCAKI,iBAKJ,mBAEE,mBAGA,6CAJA,aAMA,eACA,eALA,gBACA,MAEA,oBAQA,YPjCc,CO6Bd,wBAVF,mBA5BI,cAwCA,iBAOF,6BACE,kDAIF,0CACE,UAIF,yCAEE,mBADA,aAEA,WP1CoB,CO2CpB,WAIF,wCAEE,mBADA,YACA,CAOF,2CACE,aAIF,wBAUE,mBANA,YADA,kCAMA,aAPA,iBAGA,mBACA,mBAIA,CAGA,4BACE,aAIF,2DAGE,YADA,gCACA,CACA,yFACE,cAGJ,8BACE,gBAKA,8CACE,aAMN,gCAEE,mBADA,YACA,CAGF,wCAEE,SAGA,sIAGE,UAIF,uFAEE,+BAEF,6FAEE,iCACA,wMAEE,iCAMN,kCAaE,6CADA,qCCvJF,+FACE,CDwJA,kCAPA,SACA,0BAMA,CAZA,wCACE,cAaF,iDAEE,mBADA,oBAYA,cAVA,iBAUA,CAPA,uDAEE,yBACA,iCAFA,oBAEA,CAOF,0DACE,WAGF,0EAEE,mBACA,oBACA,uBAHA,WAGA,CEvMR,WAEE,iBAIA,iCACE,aCHJ,oBAGE,iBAGA,aAJA,MAOA,gFACE,CAIF,wBAdF,oBAgBI,cAIF,kDACE,gBAIF,wBAzBF,oBA0BI,cVF+B,CUUjC,6EAGE,iBAEA,SAAQ,CADR,iBACA,CVf+B,CWxBnC,sBAEE,MAEA,yBAJF,sBAMI,cAIF,+CAEE,aACA,UAFA,SAEA,CAGA,uEAEE,gBAAe,CADf,aACA,CAKJ,kCAKE,mBAEA,6BAJA,aACA,UAHA,WXDoB,CWMpB,SAJA,eAKA,CAIF,yBAlCF,sBAmCI,uCACA,mBAOA,SAAQ,CANR,+BAGA,SAGA,CAGA,gCAEE,2CAEA,cAGA,6CAEE,gBAGA,4BAMJ,uCAEE,eX3CkB,CW4ClB,kBAGA,iDACE,yCAIF,yDAEE,YACA,iCACA,gBAHA,UAIA,kBACA,4BAIF,oDACE,WCvFR,OACE,uCACA,yBAIE,0BAHA,aACA,eAGA,gBAFA,YZ6BoB,CY1BpB,mDACE,eACA,qDACE,gBCdR,mBACE,eACA,wBAFF,mBAII,iBCJJ,iBASE,gBALA,yBAJF,iBAKI,wBCDF,uCACE,iBAIE,yGAEE,iBAIF,qDACE,gBChBR,cAKE,sBAEA,WANA,aAKA,uBAJA,gBAKA,CAGA,oBACE,qBAEF,2BACE,kBAEA,kBADA,kBACA,CAGF,2BACE,aCnBJ,qBACE,WAGE,oDACE,aAMN,qBAIE,aAFA,gBADA,UAGA,CAEA,kDACE,iBAKJ,wBACE,eACE,uBAGF,qBACE,cAMJ,cAEE,kBADA,kBACA,CACA,wBAHF,cAKI,kBADA,kBACA,EAKA,wBAFF,+BAGI,cACA,iCACE,gBChDR,IACE,eAEA,iBAGE,cAFA,iBACA,iBACA,CAGF,eACE,WACA,WACA,iBAGF,gBACE,YACA,YACA,gBAKJ,WAEE,kBACA,kBAFA,UAEA,CAEA,sBACE,gBACA,gCACE,cAGJ,uBACE,iBACA,iCACE,eAIJ,qBACE,gBAKA,gEACE,cAIJ,oCACE,gBAGF,+BACE,gBAGF,gBACE,gBCHJ,oBACE,gBACA,qCACE,aAEF,wBACE,iBAEF,wBARF,oBAUI,cADA,cACA,CACA,qCACE,eACA,2CACE,aAMR,oBACE,aACA,wBACE,8EAKE,WAHA,cACA,WACA,UAGA,iBACA,kBAFA,SAEA,EAKN,8BAlEE,uBA0EA,iBA3EA,YAEA,eACA,kBAmEA,kBAvEA,UAsEA,SAMA,CAJA,sCACE,iBAlEF,8BA6DF,8BAxDI,YAHA,kBADA,SAIA,CAEA,8DAEE,mBADA,oBAEA,eAGA,kEACE,eACA,iBAuDN,wBATF,8BAUI,cAKF,oBAEE,YACA,iBAGF,gCACE,mBAWF,0CACE,aAMF,iCACE,aACA,eACA,gBAGA,mDACE,cACA,eAIJ,wBAtBF,qBAwBI,YAGA,iCACE,cACA,kBAKN,mGAlIE,uBADA,YAEA,eACA,kBAuIA,kBA3IA,UA0IA,SAtIA,CAGA,8BA6HF,mGAxHI,YAHA,kBADA,SAIA,CAEA,mMAEE,mBADA,oBAEA,eAGA,+MACE,eACA,iBAyHN,ySACE,eAKJ,0GAnJE,uBADA,YAEA,eACA,kBAqJA,kBAzJA,UAwJA,SApJA,CAGA,8BA8IF,0GAzII,YAHA,kBADA,SAIA,CAEA,0JAEE,mBADA,oBAEA,eAGA,gKACE,eACA,iBAwIR,2BACE,gBAUF,8EAKE,kBADA,SACA,CACA,wBANF,8EAOI,cATsB,CAUtB,UAVsB,EC7LxB,gEAKE,6CADA,iBADA,gBAEA,CAGF,+BAIE,cAFA,eADA,kBAIA,kBAFA,gBAEA,CCjBJ,2BAEE,WCIF,+HACE,gBACA,gBCFF,kBACE,kCAEE,cCNJ,eACE,sBACA,4BAGF,+BACE,4BAGF,yBACE,0BAGF,2BAEE,cADA,YACA","sources":["webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/index.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/abstracts/_variables.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/base/_base.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/base/_typography.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/base/_print.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_announcement.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_article.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_article-container.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_header-article.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/abstracts/_mixins.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_header-primary.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_sidebar-primary.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_sidebar-secondary.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_footer-content.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_footer-article.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_back-to-top.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_icon-links.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_logo.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_search.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_images.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_margin.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_quotes.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_code.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_notebooks.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/extensions/_comments.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/extensions/_thebe.scss"],"sourcesContent":["/*! sphinx-book-theme CSS\n * BSD 3-Clause License\n * Copyright (c) 2020, EBP\n * All rights reserved.\n *\n * This follows the 7-1 pattern described here:\n * https://sass-guidelin.es/#architecture\n */\n// Variables and re-usable SCSS functions\n@import \"abstracts/mixins\";\n@import \"abstracts/variables\";\n\n// Basic styling applied throughout site\n@import \"base/base\";\n@import \"base/typography\";\n@import \"base/print\";\n\n// Major theme layout, skeleton, and whitespace\n@import \"sections/announcement\";\n@import \"sections/article\";\n@import \"sections/article-container\";\n@import \"sections/header-article\";\n@import \"sections/header-primary\";\n@import \"sections/sidebar-primary\";\n@import \"sections/sidebar-secondary\";\n@import \"sections/footer-content\";\n@import \"sections/footer-article\";\n\n// Re-usable components across the theme\n@import \"components/back-to-top\";\n@import \"components/icon-links\";\n@import \"components/logo\";\n@import \"components/search\";\n\n// Content blocks in standard Sphinx\n@import \"content/images\";\n@import \"content/margin\";\n@import \"content/quotes\";\n@import \"content/code\";\n@import \"content/notebooks\";\n\n// Content blocks from Sphinx extensions\n\n@import \"extensions/comments\";\n@import \"extensions/thebe\";\n","/*********************************************\n* Variables *\n*********************************************/\n// Breakpoints from Bootstrap: https://getbootstrap.com/docs/5.0/layout/breakpoints/\n$breakpoint-xxl: 1200px;\n$breakpoint-xl: 1200px;\n$breakpoint-lg: 992px;\n$breakpoint-md: 768px;\n$breakpoint-sm: 576px;\n\n// A few semantic z-indices\n$zindex-bottom: 1;\n$zindex-middle: 2;\n$zindex-top: 3;\n\n// Semantic Z-index from bootstrap. Copied here so we can re-use if needed.\n// ref: https://getbootstrap.com/docs/5.0/layout/z-index/\n$zindex-dropdown: 1000;\n$zindex-sticky: 1020;\n$zindex-fixed: 1030;\n$zindex-modal-backdrop: 1040;\n$zindex-offcanvas: 1050;\n$zindex-modal: 1060;\n$zindex-popover: 1070;\n$zindex-tooltip: 1080;\n\n// Spacing\n$header-article-height: 3rem;\n$sidebar-primary-width-widescreen: 20%;\n$toc-width-mobile: 75%;\n\n// Consistent styling for page elements\n$box-border-radius: 0.4em;\n\n$animation-time: 0.25s;\n\n// Font sizes\n$sbt-font-size-small-1: 87.5%;\n\n/**\n * Variables that aren't impacted by light/dark\n */\nhtml[data-theme=\"light\"],\nhtml[data-theme=\"dark\"] {\n // Over-ride the pydata theme so that readers can use their system base\n --pst-font-size-base: none;\n // Default secondary color (has enough contrast on both light/dark so\n // no need to special case.\n --pst-color-secondary: #e89217;\n}\n\n// Overrides for pydata sphinx theme.\n// See https://github.com/pydata/pydata-sphinx-theme/blob/master/pydata_sphinx_theme/static/css/theme.css\nhtml[data-theme=\"light\"] {\n // Announcement\n --sbt-color-announcement: rgb(97, 97, 97);\n // Default primary color (need to adjust on dark theme due to bad contrast)\n --pst-color-primary: #176de8;\n}\n\nhtml[data-theme=\"dark\"] {\n // Slightly lighten these colors to make them stand out more on dark\n --pst-color-primary: #528fe4;\n\n // Over-ride the purple announcement color\n --sbt-color-announcement: rgb(97, 97, 97);\n // Desaturate the background\n --pst-color-background: #121212;\n}\n","/**\n * General structural things\n */\nhtml {\n // The PyData theme value for this is based on `header-height` variable.\n // We set the variable to 0 and have our own $article-header-height SCSS variable.\n // So here we follow the same pattern but now using our variable.\n scroll-padding-top: $header-article-height + 1rem;\n}\n\n/**\n* Utility classes used in a few places\n*/\n// For the helper pixel that we can watch to decide whether we've scrolled\n.sbt-scroll-pixel-helper {\n position: absolute;\n width: 0px;\n height: 0px;\n top: 0;\n left: 0;\n}\n\n// We define our own display-none class since bootstrap uses !important and we want to be able to over-ride\n.d-n {\n display: none;\n}\n\n/**\n * Printing behavior\n */\n// Only display upon printing\n.onlyprint {\n display: none;\n\n @media print {\n display: block !important;\n }\n}\n\n// Prevent an item from being printed\n.noprint {\n @media print {\n display: none !important;\n }\n}\n","/*********************************************\n* Basic text formatting and content structure *\n*********************************************/\n\n.bd-article-container {\n h1,\n h2,\n h3,\n h4,\n h5,\n p.caption {\n color: var(--pst-color-muted);\n }\n\n // Top two headers are slightly bolder\n h1,\n h2 {\n font-weight: 500;\n }\n}\n\n// counteracting pydata style on a::before, for citation style\na.brackets::before {\n color: inherit;\n font-family: inherit;\n margin-right: 0rem;\n}\n\ntable {\n position: relative;\n}\n","/*********************************************\n* Print-specific CSS *\n*********************************************/\n@media print {\n .bd-main {\n .bd-content {\n margin-left: 2rem;\n height: auto;\n // Structural elements\n #jb-print-docs-body {\n margin-left: 0rem;\n\n h1 {\n font-size: 3em;\n text-align: center;\n margin-bottom: 0;\n }\n }\n // Main content adjustments\n .bd-article {\n padding-top: 0;\n\n // The first H1 is the title, we've already displayed above\n h1:first-of-type {\n display: none;\n }\n }\n\n // HACK: Without this, some code cells take the whole width\n .container {\n min-width: 0% !important;\n }\n\n // Content\n h1 {\n margin-top: 1em;\n margin-bottom: 1em;\n }\n h1,\n h2,\n h3,\n h4 {\n break-after: avoid;\n color: black;\n }\n\n table {\n break-inside: avoid;\n }\n\n pre {\n word-wrap: break-word;\n }\n\n a.headerlink {\n display: none;\n }\n\n // Remove borders to save some ink\n blockquote.epigraph,\n aside.margin,\n aside.sidebar {\n border: none;\n }\n\n .footer {\n margin-top: 1em;\n }\n // Print-only table of contents\n #jb-print-toc {\n margin-bottom: 1.5rem;\n margin-left: 0rem;\n .section-nav {\n border-left: 0px !important;\n list-style-type: disc !important;\n margin-left: 3em !important;\n a {\n text-decoration: none !important;\n }\n li {\n display: list-item !important;\n }\n .nav {\n display: none;\n }\n }\n }\n }\n\n // Hide the footer on printing\n .bd-footer-content {\n display: none !important;\n }\n }\n}\n",".bd-header-announcement {\n background-color: var(--sbt-color-announcement);\n color: #fff;\n}\n",".bd-main .bd-content {\n // make article container left aligned in absence of sidebar\n justify-content: left;\n}\n",".bd-main .bd-content .bd-article-container {\n // Re-adjust padding defaults to be flush on the top and right\n padding: 0rem;\n // Unset overflow x so that sticky: top works for the article header\n overflow-x: unset;\n // prevent from overflowing the flex container\n min-width: 0;\n\n @media (min-width: $breakpoint-xl) {\n // keep article at reasonable width in absence of sidebar\n max-width: calc(100% - var(--pst-sidebar-secondary));\n }\n\n .bd-article {\n padding-right: 2rem;\n padding-left: 2rem;\n @media (max-width: $breakpoint-md) {\n padding-right: 1rem;\n padding-left: 1rem;\n }\n }\n details.above-input,\n details.below-input {\n summary {\n border-left: 3px solid var(--pst-color-primary);\n }\n }\n}\n","/*********************************************\n* Top Bar *\n*********************************************/\n/**\n * Mixin:\n * Header behavior on mobile\n */\n@mixin header-height-mobile {\n @media (max-width: $breakpoint-md) {\n height: $header-article-height + 0.5rem;\n }\n}\n\n/**\n * Sidebar toggle over-rides for PST\n */\n// Primary toggle is always visible\nbutton.sidebar-toggle.primary-toggle {\n @media (min-width: $breakpoint-md) {\n display: inline-block;\n }\n @media (max-width: $breakpoint-md) {\n margin-bottom: 0px;\n }\n}\n\n// Secondary toggle mimics behavior of \"persistent header\" div of PST\nbutton.sidebar-toggle.secondary-toggle {\n @media (min-width: $breakpoint-xl) {\n display: none;\n }\n @media (max-width: $breakpoint-md) {\n margin-bottom: 0px;\n }\n}\n\n// Wrapper container\n.bd-header-article {\n display: flex;\n align-items: center;\n position: sticky;\n top: 0;\n background-color: var(--pst-color-background);\n transition: left 0.2s;\n font-size: 0.9em;\n padding: 0 1rem;\n\n @media (max-width: $breakpoint-md) {\n // Give mobile view a bit more space for text\n padding: 0 0.5rem;\n }\n z-index: $zindex-sticky;\n\n @include header-height-mobile;\n\n // The box shadow that shows up when you've scrolled past the top\n .scrolled & {\n box-shadow: 0 6px 6px -6px var(--pst-color-shadow);\n }\n\n // Remove inner padding so that spacing of buttons is a bit tighter\n .header-article__inner {\n padding: 0;\n }\n\n // Inner container with items in it\n .header-article-items {\n display: flex;\n align-items: center;\n height: $header-article-height;\n width: 100%;\n }\n\n // Contains the individual item components so we want it centered\n .header-article-item {\n display: flex;\n align-items: center;\n }\n\n /**\n * Buttons in the header\n */\n // A series of buttons we special-case in the theme\n .article-header-buttons {\n display: flex;\n }\n\n // Generic button styles\n .btn {\n // Basic button size\n font-size: 1.3rem;\n color: var(--pst-color-text-muted);\n border: none;\n padding-left: 0.5rem;\n padding-right: 0.5rem;\n\n // Make sure anything inside is aligned vertically\n display: flex;\n align-items: center;\n\n // Fix width of buttons so they're all the same\n svg {\n width: 1.3rem;\n }\n\n // Hover / active behavior\n &.show,\n &:hover {\n color: var(--pst-color-text-base);\n border: none;\n & + .dropdown-menu {\n display: block;\n }\n }\n &:focus {\n box-shadow: none;\n }\n\n &.dropdown-toggle {\n // Hide the bootstrap caret\n &:after {\n display: none;\n }\n }\n }\n\n // Vertically align dropdown buttons\n div.dropdown {\n display: flex;\n align-items: center;\n }\n\n .theme-switch-button {\n // Removing some special-casing that was needed in PST\n margin: 0;\n\n // Remove extra padding since it is already there between sidebar items\n span,\n i,\n button {\n padding: 0;\n }\n\n // No background on hover. Need important to over-ride the PST which uses it too.\n span,\n i {\n transition: color $animation-time ease-out;\n }\n &:active,\n &:hover {\n background-color: unset !important;\n span,\n i {\n color: var(--pst-color-text-base);\n }\n }\n }\n\n // The menu that is normally hidden until you hover\n .dropdown-menu {\n // Hidden unless we are hovering\n &:hover {\n display: block;\n }\n\n // Positioning and layout of dropdown items to be standardized\n top: 2rem;\n transform: translateX(-75%);\n @include pst-box-shadow;\n\n // Color and shadowing\n border-color: var(--pst-color-border);\n background-color: var(--pst-color-background);\n color: var(--pst-color-text-muted);\n\n .dropdown-item {\n display: inline-flex;\n align-items: center;\n padding-left: 0.5em;\n\n // To prevent link underline from showing up\n &:hover {\n text-decoration: none;\n background-color: initial;\n color: var(--pst-color-text-base);\n }\n\n // Slightly smaller font for everything\n font-size: 1em;\n\n // Image icons should be the same height as icons\n span img {\n height: 1em;\n }\n\n span.btn__icon-container {\n width: 1.7em;\n align-items: center;\n display: inline-flex;\n justify-content: center;\n }\n }\n }\n}\n","/*********************************************\n* SASS Mixins\n*********************************************/\n/**\n* Hide the scrollbar until the element is hovered, so keep the page clean\n* Use this sparingly because it's not a great UX pattern.\n*/\n@mixin scrollbar-on-hover() {\n &:not(:hover) {\n &::-webkit-scrollbar-thumb {\n visibility: hidden;\n }\n }\n}\n\n/**\n * The PyData Sphinx Theme box shadow rule\n * Copied here in csae we need to re-use.\n*/\n@mixin pst-box-shadow() {\n box-shadow:\n 0 0.2rem 0.5rem var(--pst-color-shadow),\n 0 0 0.0625rem var(--pst-color-shadow) !important;\n}\n",".bd-header {\n // Turn off sticky positioning so that it scrolls\n position: inherit;\n\n // Turn these off because we'll show it in the article header\n // The primary sidebar toggle\n button.sidebar-toggle {\n display: none;\n }\n}\n","/*********************************************\n* Left Nav Bar *\n*********************************************/\n\n.bd-sidebar-primary {\n // So that it sticks to the top of the page instead of the header height\n top: 0;\n max-height: 100vh;\n\n // Tighter padding so the spacing is more equal\n padding: 1rem;\n\n // Draw open/close animation\n transition:\n margin-left $animation-time ease 0s,\n opacity $animation-time ease 0s,\n visibility $animation-time ease 0s;\n\n @media (max-width: $breakpoint-md) {\n // So that tooltips don't overlap\n z-index: $zindex-tooltip + 1;\n }\n\n // Remove the top border since there's often no header items above\n .sidebar-primary-items__start {\n border-top: none;\n }\n\n // On wide screens we have a smaller sidebar width than PST\n @media (min-width: $breakpoint-lg) {\n flex-basis: $sidebar-primary-width-widescreen;\n }\n}\n\n// Default visibility for left sidebar is the reverse of what it is on mobile.\n// It is shown by default, and hidden with a click.\n// Mobile behavior is defined in the pydata sphinx theme\n@media (min-width: $breakpoint-lg) {\n input#pst-primary-sidebar-checkbox:checked\n ~ .bd-container\n .bd-sidebar-primary {\n margin-left: -$sidebar-primary-width-widescreen;\n visibility: hidden;\n opacity: 0;\n }\n}\n","/*********************************************\n* Table of Contents (right nav bar) *\n*********************************************/\n\n.bd-sidebar-secondary {\n // So that it sticks to the top of the page instead of the header height\n top: 0;\n\n @media (max-width: $breakpoint-xl) {\n // So that tooltips don't overlap\n z-index: $zindex-tooltip + 1;\n }\n\n // So that we can center the TOC button with the article header buttons\n .sidebar-secondary-items {\n padding: 0;\n display: flex;\n gap: 0.5rem;\n\n // Remove the manual padding since we'll use `gap`\n .sidebar-secondary-item {\n padding-top: 0;\n padding-bottom: 0;\n }\n }\n\n // The 'on this page' title div should take up the full header\n .onthispage {\n height: $header-article-height;\n min-height: $header-article-height;\n display: flex;\n gap: 0.5rem;\n align-items: center;\n margin: 0;\n color: var(--pst-color-muted);\n }\n\n // Wide screen behavior\n @media (min-width: $breakpoint-xl) {\n background: var(--pst-color-background);\n height: fit-content;\n transition: max-height 0.4s ease;\n\n // To make sure it shows above the page content\n z-index: $zindex-middle;\n\n // Remove padding so that it's flush on the top and left\n padding: 0;\n\n // This is the container div for the secondary sidebar nav\n .toc-item {\n // Border is a bit less prominent\n border-left-color: var(--pst-color-surface);\n // Flush with the top so that we can fix the height of the toc header div\n padding-top: 0;\n\n // The table of contents